Re: RFC: adding pytest as a supported test framework

On Wed, 12 Jun 2024 at 18:46, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
> This is true, but [citation needed] :D I assume the pointer wanted to
> be https://www.psycopg.org/psycopg3/docs/api/pq.html#pq-impl

Ugh, yes I definitely meant to add a link to that [1]. I meant this one though:

[1]: https://www.psycopg.org/psycopg3/docs/basic/install.html#pure-python-installation

> - using the pure Python psycopg (enforced by exporting
> 'PSYCOPG_IMPL=python') you would use the libpq found on the
> LD_LIBRARY_PATH, which can be useful to test regressions to the libpq
> itself.

This indeed was the main idea I had in mind.

> - if you want to test new libpq functions you can reach them in Python
> by dynamic lookup. See [2] for an example of a function only available
> from libpq v17.
>
> [2]:
https://github.com/psycopg/psycopg/blob/2bf7783d66ab239a2fa330a842fd461c4bb17c48/psycopg/psycopg/pq/_pq_ctypes.py#L564-L569

Yeah, that dynamic lookup would work. But due to the cyclic dependency
on postgres commit vs psycopg PR we couldn't depend on psycopg for
those dynamic lookups. So we'd need to have our own dynamic lookup
code to do this.

I don't see a huge problem with using psycopg for already released
commonly used features (i.e. connecting to postgres and doing
queries), but still use our own custom dynamic lookup for the rare
tests that test newly added features. But I can definitely see people
making the argument that if we need to write & maintain some dynamic
lookup code ourselves anyway, we might as well have all the dynamic
lookup code in our repo to avoid dependencies.

On Wed, 12 Jun 2024 at 18:46, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
>
> On Wed, 12 Jun 2024 at 18:08, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> >
> > On Wed, 12 Jun 2024 at 17:50, Andres Freund <andres@anarazel.de> wrote:
> > > > The OAuth pytest suite makes extensive use of
> > > > - psycopg, to easily drive libpq;
> > >
> > > That's probably not going to fly. It introduces painful circular dependencies
> > > between building postgres (for libpq), building psycopg (requiring libpq) and
> > > testing postgres (requiring psycopg).
> >
> > psycopg has a few implementations binary, c, & pure python. The pure
> > python one can be linked to a specific libpq.so file at runtime[1]. As
>
> This is true, but [citation needed] :D I assume the pointer wanted to
> be https://www.psycopg.org/psycopg3/docs/api/pq.html#pq-impl
>
> I see the following use cases and how I would use psycopg to implement them:
>
> - by installing 'psycopg[binary]' you would get a binary bundle
> shipping with a stable version of the libpq, so you can test the
> database server regardless of libpq instabilities in the same
> codebase.
> - using the pure Python psycopg (enforced by exporting
> 'PSYCOPG_IMPL=python') you would use the libpq found on the
> LD_LIBRARY_PATH, which can be useful to test regressions to the libpq
> itself.
> - if you want to test new libpq functions you can reach them in Python
> by dynamic lookup. See [2] for an example of a function only available
> from libpq v17.
>
> [2]:
https://github.com/psycopg/psycopg/blob/2bf7783d66ab239a2fa330a842fd461c4bb17c48/psycopg/psycopg/pq/_pq_ctypes.py#L564-L569
>
> -- Daniele