search

aleaxit / gmpy

General Multi-Precision arithmetic for Python 2.6+/3+ (GMP, MPIR, MPFR, MPC)
https://gmpy2.readthedocs.io/en/latest/
GNU Lesser General Public License v3.0
506 stars 84 forks source link

Impending release of gmpy2 2.2.0a2 #462

Open casevh opened 7 months ago

casevh commented 7 months ago

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 commented 7 months ago

You forgot to include header files (gmp.h, etc), as it was promised in https://github.com/aleaxit/gmpy/issues/352#issuecomment-1839013507

casevh commented 7 months ago

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 https://github.com/aleaxit/gmpy/issues/447#issuecomment-1863918702 for more details.

skirpichev commented 7 months ago

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 commented 7 months ago

See https://github.com/aleaxit/gmpy/issues/447#issuecomment-1863968348

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 commented 7 months ago

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

casevh commented 7 months ago

I like it!

rgommers commented 6 months ago

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 commented 5 months ago

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 commented 4 months ago

@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 commented 3 months ago

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

CC #476