Re: RFC: adding pytest as a supported test framework - Mailing list pgsql-hackers

Hi,

On 2026-01-06 20:07:22 +0100, Jelte Fennema-Nio wrote:
> On Mon Jan 5, 2026 at 9:19 PM CET, Jacob Champion wrote:
> > On Wed, Dec 17, 2025 at 8:10 AM Andres Freund <andres@anarazel.de> wrote:
> > Before it gets too far away from me: note that I have not yet been
> > able to get up to speed with the combined refactoring+feature patch
> > that Jelte added in v3, and it's now up to v7,
> 
> Attached is v8. It simplifies the Cirrus CI yaml, because the
> dependencies are now baked into the images. I also removed the optional
> dependency on uv. Meson/autoconf now simply search for pytest binary in
> the .venv directory too. Devs can then choose if they want to populate
> .venv with pip or uv. Finally, if the pytest binary cannot be found,
> there's a fallback attempt to use `python -m pytest`.

I'm somewhat sceptical that the .venv support should be introduced together
with the rest of this.


> > > > -SUBDIRS = perl postmaster regress isolation modules authentication recovery subscription
> > > > +SUBDIRS = \
> > > > +     authentication \
> > > > +     isolation \
> > > > +     modules \
> > > > +     perl \
> > > > +     postmaster \
> > > > +     pytest \
> > > > +     recovery \
> > > > +     regress \
> > > > +     subscription
> > > 
> > > I'm onboard with that, but we should do it separately and probably check for
> > > other cases where we should do it at the same time.
> > 
> > I'm not sure what context this is referring to? What are you on board with?
> 
> If I understood Andres correctly this was about splitting the items
> across multiple lines.

Yep.


> I moved this to a separate thread, and it was
> cammitted by Michael in 9adf32da6b. So this has been resolved afaik.

Yay.


> > > I think it'd be a seriously bad idea to start with no central infrastructure,
> > > we'd be force to duplicate that all over.
> > 
> > Right, I just want central infra to be pulled out of the new tests
> > that need them rather than the other way around.

> I'm not sure how you expect that to work in practice. I believe (and I
> think Andres too) that there's some infra that we already know we'll
> need for many tests, e.g. starting/stopping nodes, running queries,
> handling errors.

Yes, I do indeed agree with that.


> I don't think it makes sense to have those be pulled
> out of new tests. You need some basics, otherwise no-one will want to
> write tests. And even if they do, everyone ends up with different styles
> of doing basic things. I'd rather coordinate on a bit of style upront so
> that tests behave similarly for common usages.

Indeed. I'm fairly fundamentally opposed to merging any of this without first
having developed the basic infrastructure.


Greetings,

Andres Freund