Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Changes for flint 3.0 #49

Closed
deinst opened this issue Aug 11, 2023 · 2 comments
Closed

Changes for flint 3.0 #49

deinst opened this issue Aug 11, 2023 · 2 comments

Comments

@deinst
Copy link
Contributor

deinst commented Aug 11, 2023

  1. nmod_poly_factor has its own include file -- minor change to _flint.pxd
  2. The arb library no longer exists (it was rolled into flint). -- minor change to setup.py

I am not sure how to fix either of these in a way that allows either flint 2.9 or 3.0 to be used, as it would involve querying the flint headers before compilation.

@oscarbenjamin
Copy link
Collaborator

I have a PR ready for flint 3 (gh-43). Looks like it has merge conflicts now but otherwise it previously passed all CI checks except for the Flint bug fixed in flintlib/flint#1416.

It probably is possible to make python-flint compatible with both 2.9 and 3.0 but I don't think it is worth doing. Currently python-flint has very tight version constraints i.e. only exactly flint 2.9 and Arb 2.23 (I think). Nothing newer will work (flint3) and nothing older will work. Basically unless someone specifically compiles the exact versions with the intent to build python-flint then they won't have the right versions. That is of course fine for the binary wheels which are built with the exact versions needed.

Python-flint is basically resurrected at the exact moment that flint is transitioning to flint 3 and does not currently have wide version support. I think it makes sense to just drop flint 2.9 as soon as flint 3 is released. Anyone who wants python-flint for flint 2.9 can use the current version of python-flint (0.4.1).

From there though I think it makes sense for python-flint to keep flint 3 as a minimum supported version probably for years i.e. long enough that it could make sense to build new versions of python-flint against e.g. distro provided builds of flint 3. Already python-flint is some way behind the existing features of flint so not using any newer features is unlikely to be a significant constraint any time soon.

@oscarbenjamin
Copy link
Collaborator

This issue is very dated now since python-flint migrated to Flint 3.0 a long time ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants