Re: RFC: adding pytest as a supported test framework
От | Jelte Fennema-Nio |
---|---|
Тема | Re: RFC: adding pytest as a supported test framework |
Дата | |
Msg-id | CAGECzQSknMq=wTMQtodo1t9LyGfApZjWyM2yAoH6je0m9oLMpQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: adding pytest as a supported test framework (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: RFC: adding pytest as a supported test framework
Re: RFC: adding pytest as a supported test framework Re: RFC: adding pytest as a supported test framework |
Список | pgsql-hackers |
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). > > You *can* solve such issues, but we've debated that in the past, and I doubt > we'll find agreement on the awkwardness it introduces. 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 long as we don't break the libpq API (which we shouldn't), we can just point it to the libpq compiled by meson/make. We wouldn't be able to use the newest libpq features that way (because psycopg wouldn't know about them), but that seems totally fine for most usages (i.e. sending a query over a connection). If we really want to use those from the python tests we could write our own tiny CFFI layer specifically for those. > One thing worth thinking about is that such dependencies have to work on a > relatively large number of platforms / architectures. A lot of projects > don't... Do they really? A bunch of the Perl tests we just skip on windows or uncommon platforms. I think we could do the same for these.
В списке pgsql-hackers по дате отправления: