BLD: automatically detect if in freethread build of Python #158
Conversation
setup.py
Outdated
| # build with Py_LIMITED_API unless explicitly disabled | ||
| USE_PY_LIMITED_API = os.getenv("PYERFA_LIMITED_API", "1") != "0" | ||
| USE_PY_LIMITED_API = ( | ||
| (not sysconfig.get_config_var("Py_GIL_DISABLED")) and |
There was a problem hiding this comment.
Thanks for the PR! The link you give makes sense, but I'm still confused - this piece is about building, not running, and might we not want to build without the limited API on a regular, GIL-enabled python? cc @neutrinoceros, since he just put this in.
There was a problem hiding this comment.
I don't know of a reason to build with the GIL and without Limited API, but the reason I specifically didn't implement this automatic switch is that it's only expected to be relevant for Python 3.13t, as 3.14t is expected to support the Limited API. That said, I made this choice before the guide had a recommendation there (or maybe before I learned about it), and maybe it's easier to follow a convention than having our own solution in place.
There was a problem hiding this comment.
My intent with this change was to preserve the ability to build with GIL and with not-limited.
As a random person trying to build packages (https://github.com/tacaswell/build_the_world), not having to set an pyerfa specific ENV is very convenient!
There was a problem hiding this comment.
OK, that makes sense - thanks, @neutrinoceros and @tacaswell!
@neutrinoceros - do we still need your special variable?
There was a problem hiding this comment.
My env var not used anywhere yet, and @tacaswell´s argument makes a lot of sense, so I say let's roll with it. Thanks !
There was a problem hiding this comment.
@neutrinoceros - So, remove your environment variable then in favor of this? (Right now, setting the environment variable is still kept as an option.)
There was a problem hiding this comment.
@tacaswell - are you able to make the small change requested? (Remove support for @neutrinoceros's environment variable.) If not, we can do it.
|
I made the code changes, but do not have time today to track down if there are doc changes that need to be made as well. I have no problem with people pushing to this branch / closing this and re-creating a new PR. My to-do list is always longer than I have time to actually do so do not wait for me! |
|
@mhvk downstream is starting to hit build issues with cp313: https://github.com/cds-astro/mocpy/actions/runs/11345966890/job/31553997210 |
|
@neutrinoceros - I had been waiting for a new SOFA release, but if there are problems that can be solved now, obviously we should go ahead, so I made a point release now. Thanks for the heads-up! |
Following suggestion from:
https://docs.python.org/3.13/howto/free-threading-extensions.html#limited-c-api-and-stable-abi