Git Product home page Git Product logo

Comments (10)

skirpichev avatar skirpichev commented on June 24, 2024

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

from gmpy.

casevh avatar casevh commented on June 24, 2024

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.

from gmpy.

skirpichev avatar skirpichev commented on June 24, 2024

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.

from gmpy.

casevh avatar casevh commented on June 24, 2024

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.

from gmpy.

isuruf avatar isuruf commented on June 24, 2024

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

from gmpy.

casevh avatar casevh commented on June 24, 2024

I like it!

from gmpy.

rgommers avatar rgommers commented on June 24, 2024

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.

from gmpy.

tobiasdiez avatar tobiasdiez commented on June 24, 2024

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).

from gmpy.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.