Feedback-ID: id4a34324:Fastmail
Date: Tue, 6 Jan 2026 18:17:50 -0500
From: Andres Freund <andres@anarazel.de>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Jacob Champion <jacob.champion@enterprisedb.com>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>, 
	Daniel Gustafsson <daniel@yesql.se>, Tom Lane <tgl@sss.pgh.pa.us>, 
	Peter Eisentraut <peter@eisentraut.org>, Nazir Bilal Yavuz <byavuz81@gmail.com>
Subject: Re: RFC: adding pytest as a supported test framework
Message-ID: <baqtdyuunu42yu7ler4bflifksznt7u7tywj4atdtcxwxhxinj@76taubczsku2>
References: <2302192.1718380169@sss.pgh.pa.us>
 <CAOYmi+k214g1tgREvQkUcr=OCiVKyaTDu1ja+OGAygG1y=jhPQ@mail.gmail.com>
 <CAOYmi+nEqA2LmetcJKUDmctypPLLumkVwj3vQ3idYd8yAGza5Q@mail.gmail.com>
 <CAOYmi+kebAt6wSX7ee0c0kMzV7r0hp93bAt10V5a88yHHUKwog@mail.gmail.com>
 <CAOYmi+=CrBFBRX-foRRES2tx2wXBJJhbsJGjgFbWvPcmBJuK-Q@mail.gmail.com>
 <DDOUZE2TCU8O.89TN0AS4GLP7@jeltef.nl>
 <DE5BODEZ607Y.3LNII22O5N27O@jeltef.nl>
 <g4gdtfedwwdgu5sbcopjt3djtqk6p2q7n5nymp7ppapfwukoyd@ev2v4jtsbure>
 <CAOYmi+mV97+FC=ME0EZj+3LBFHZ3g_xGmTGA_3u+TwJ_pvpFWw@mail.gmail.com>
 <DFHQQ4VS43SU.25NN2Y5GDWANL@jeltef.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <DFHQQ4VS43SU.25NN2Y5GDWANL@jeltef.nl>
Archived-At: <https://www.postgresql.org/message-id/baqtdyuunu42yu7ler4bflifksznt7u7tywj4atdtcxwxhxinj%4076taubczsku2>
Precedence: bulk

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