Feedback welcome for new psycopg2 binary packages

Hello,

I will release soon psycopg2 v. 2.9. This version only targets Python >= 3.6 so I moved the package build system to manylinux_2_24 (PEP 660).

I would kindly ask anyone informed about the topic if they could provide some feedback about the build system and if we are doing anything wrong. Packages are built by GitHub actions using the scripts available in this directory.

The packages are available on testpypi and can be tried out with:

pip install -i https://test.pypi.org/simple psycopg2-binary==2.9.0.dev0

Thank you very much!

– Daniele

Hello,

Just had a quicklook and here are my thoughts (just by looking, not tested anything):

  • PEP 600 is fairly new and support for it was added into pip “very” recently. This means that some of your users will probably end up building from sources. It’s something to have in mind. You can find the list of pip version needed given the policy you target on the manylinux README. You might also be interested by the stats Manylinux Timeline in this regard. It might be a bit much to digest though.

  • Using manylinux_2_24, users of non EOLed distros like CentOS 7, Amazon Linux 1 will have to build from sources (the one mentioned are using glib 2.17 => manylinux_2_17 also known as manylinux2014).

  • I can see that cp310 has been uploaded to test PyPI. As mentioned in Adding support for 3.10 pre-release to manylinux images · Issue #949 · pypa/manylinux · GitHub, CPython 3.10.0b1 has been added to allow for testing but, as the ABI is not frozen yet, you might end up uploading wheels that won’t work on the next betas/rc/final of CPython 3.10 and it’s thus not recommended to upload those to PyPI.

Edit: added a note about manylinux_2_24

Hi @mayeut, thank you for your input.

I understand the 2_24 tag requires pip 20.3, released back in November 2020. That’s certainly recent, but I have documented the need of updating pip before installing psycopg2 binary packages and updating pip is a simple operation pip itself will remind, in yellow, to do.

Providing 2_24 packages appeals for several reasons (longer life of the toolchain I’ve built, Debian being personally more familiar than Centos, but, especially, the Debian-packages libpq is built with the expected defaults, on Centos it needs to be compiled to change some config settings). But Centos 7 seems EOL’d in 2024, which is a long time away. So maybe I should reconsider this choice. Thank you very much for pointing it out. Is there a place where I could get some documentation about the compatibility grid between glib versions and OS releases?

Also thank you very much for pointing out to not release 3.10 packages on real PyPI before the final version is released; I will delay their release until the right time.

So it seems that releasing manylinux2014 packages would be a better choice for the moment, right?

Cheers

– Daniele

This is obviously at your discretion, as a psycopg2 maintainer, you’re in the best position to know your users.
My personal recommendation would be manylinux2014 based on the following (& given that pip compatibility is not considered an issue per your comment):
GitHub - ofek/pypinfo: Easily view PyPI download statistics via Google's BigQuery. reveals a bit more than 10% downloads for psycopg2 2.8.* are for Linux systems with glibc between 2.17 & 2.23 (inclusive):

Matt$ pypinfo --where 'file.project = "psycopg2" AND STARTS_WITH(file.version, "2.8.") AND details.installer.name = "pip" AND details.implementation.version >= "3.6"' -l 25 --percent psycopg2 system libc-version
Served from cache: False
Data processed: 1.31 GiB
Data billed: 1.31 GiB
Estimated cost: $0.01

| system_name          | libc_version | percent | download_count |
| -------------------- | ------------ | ------- | -------------- |
| Linux                | 2.28         |  43.79% |      2,265,479 |
| Linux                | 2.27         |  20.44% |      1,057,332 |
| Linux                | 2.31         |  12.13% |        627,576 |
| Linux                | 2.17         |   7.27% |        376,134 |
| Linux                | 2.26         |   3.84% |        198,906 |
| Linux                | 2.24         |   2.94% |        152,040 |
| Linux                | None         |   2.94% |        151,880 |
| Linux                | 2.23         |   2.78% |        143,944 |
| Darwin               | None         |   1.42% |         73,310 |
| Windows              | None         |   1.41% |         72,804 |
| Linux                | 2.19         |   0.37% |         19,230 |
| Linux                | 2.33         |   0.28% |         14,584 |
| Linux                | 2.32         |   0.17% |          8,592 |
| Linux                | 2.30         |   0.15% |          7,881 |
| Linux                | 2.12         |   0.06% |          2,954 |
| Linux                | 2.29         |   0.01% |            279 |
| FreeBSD              | None         |   0.00% |            212 |
| Linux                | 2.15         |   0.00% |            156 |
| Linux                | 2.22         |   0.00% |             75 |
| AIX                  | None         |   0.00% |             50 |
| CYGWIN_NT-10.0-19042 | None         |   0.00% |             30 |
| Linux                | 2.2.5        |   0.00% |             29 |
| Linux                | 2.18         |   0.00% |             27 |
| SunOS                | None         |   0.00% |             25 |
| CYGWIN_NT-10.0-19041 | None         |   0.00% |             25 |
| Total                |              |         |      5,173,554 |

You can get this from https://distrowatch.com
I also have a small repo which analyzes what I found available on docker which I find helpful to get an overview: GitHub - mayeut/pep600_compliance: Check manylinux policies to conform to PEP600

Thanks for building them early, though. It’s appreciated.

You should be good to release them built with the first 3.10 RC. There’s only a very small chance of needing another release before 3.10.0 final, and as part of the release team, trust me you’ll be happier making that extra release than letting whatever we fix be made permanent!