Impending release of gmpy2 2.2.0a2

[casevh]

I would like to release version 2.2.0a2 tomorrow. I have tagged the 2.2.0a2 code and uploaded a subset of the binary wheels to

https://github.com/aleaxit/gmpy/releases/tag/gmpy2-2.2.0a2

Please test any of the subset of the binary wheels if you can.

[skirpichev]

You forgot to include header files (gmp.h, etc), as it was promised in #352 (comment)

[casevh]

They are included in the Windows wheels (barring symlink corruption). #352 is related to building in the WIndows environment.

I am against supporting Cython extensions that link against gmpy2 binary wheels on Linux. Both gmpy2 and the Cython extensions should be compiled against OS provided libraries. See #447 (comment) for more details.

[skirpichev]

I am against supporting Cython extensions that link against gmpy2 binary wheels on Linux.

Then we should wipe all cython-related files from binary wheels and adjust documentation.

[casevh]

See #447 (comment)

Using Linux as an example...

Could we figure out a way to make a Linux Cython extension always see the same name-mangled libraries during a gmpy2 release cycle? Even if that means caching those version on github like I'm doing for Windows.

We need a different name (to avoid clashes) but we also need a consistent name.

That I could support.

[isuruf]

Scipy recently pacakged openblas as a separate wheel. See https://pypi.org/project/scipy-openblas64/
Maybe we can do the same here.

[casevh]

I like it!

[rgommers]

Scipy recently pacakged openblas as a separate wheel. See https://pypi.org/project/scipy-openblas64/
Maybe we can do the same here.

I'll note that SciPy uses those wheels for local development and in CI, but in the released wheels is still vendoring OpenBLAS. The problem we still have with relying on separate binary wheels is that Python packaging standards prescribe that the wheels of your package cannot have a build or runtime dependency that the sdist doesn't also have. And since we cannot add scipy-openblas32 as a dependency to an sdist (this isn't correct for an sdist, and it would break building with --no-binary :all:), this is a blocker for now.

[tobiasdiez]

Thanks for your work on the new release ❤️

Is there a time line for the 2.2 release? It is needed to get Python 3.12 support (in a couple of downstream packages like sage).

[skirpichev]

@casevh, probably this could be closed?

2.2.0a2 is available on the Github releases page, with some binary wheels included. But it's missing on PyPI.

[hartwork]

2.2.0a2 is available on the Github releases page, with some binary wheels included. But it's missing on PyPI.

CC #476