-
Notifications
You must be signed in to change notification settings - Fork 239
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
ARCH and REQUIRES_PYTHON plan #528
Comments
@joerick and @YannickJadoul, feel free to edit the above as needed, tried to paste together something actionable. @mayeut feel free to commit. @Czaki too. |
Just one minor question about 2: is that something we want to introduce now already, or only when 2.0 is in sight? |
I would introduce it now, so users who care can start explicitly pinning the min Python to 2.7. Maybe we could even print a warning if not pinned and an old wheel is built, saying it will change in 2.0 to defaulting to 3.6. I wouldn't change the default until 2.0, though, so bumping to 1.8 won't suddenly cause missing 2.7/3.5 wheels when manylinux still supports them. Not that I really expect people to read warnings in CI logs. The folding at least helps. I don't really know what @joerick plans for 2.0, basing this reasoning on SemVer. |
The days for PyPy 2 might be numbered after packaging drops support pypa/packaging#376 . Given they want to merge this before releasing a version that supports universal2 wheels, pypy2 might not be able to ever work properly on Apple Silicon. |
Minor change, now that I've played with packaging, let's make this Sadly, setuptools spells this |
Just to chime in, this plan makes sense to me! The only thing really outstanding on this is (2), the
Hmmmmmmmm I'm 50/50 on this idea, versus the |
It will complicate the option to have both |
Feel free to check out the docs example of #536; after writing the docs I'm moderately/strongly in favor of It's pretty obvious that Notice how we'd have to draw attention to a MIN_PYTHON setting, while this slips in as just another spelling for |
I see your points. The implementation/docs are neater if they share syntax. But I'm still concerned about confusion between this and BUILD/SKIP, and the name is confusing, because it reads 'cbuildwheel requires python', which is isn't right because it's the package that requires python, but even then it doesn't really require it in this context, etc. etc. Perhaps there's a way to reframe this by changing the name? I was wondering about But I must admit |
|
PS: The implementation is actually the easiest part, I'm worried about adding more complexity for users by having two ways to do this that are not the same, but not implementation. Something like this: requires_python = f'>={os.getenv("CIBW_MIN_PYTHON", "2.7")}' If we were to drop 3.5 sooner than 2.7, this would be more complicated. |
@henryiii's point about mixing the two is a valid concern, I think, though I do see the attraction of
Not really, though. We've also dropped 3.4 without issues. Once manylinux forces us to drop it (soonish?), it's just removed from the lists of identifiers. |
This is not relevant. I'm talking about dropping a default but still allowing users to build with it by setting a different value (somewhere). Once it's dropped entirely, this all becomes unneeded because we never try to build for it anyway. When we drop 3.5, it's gone. I'm just saying if our default were to become 2.7 and 3.6+ but we still do support 3.5, that would not expressible with MIN_PYTHON. I think we plan to make our default 3.6+ in 2.0 and not change it before.
That's part of why I don't like it. It's attracting people to use it instead of the proper pyproject.toml setting, and since we have to document and explain both, it's less simple than simply not having it at all and only having a direct override for pyproject.toml. |
Are there any packages that support PyPy2.7 but not CPython 2.7? I would love to think that is possible, but can not think of any examples, especially as python2.7 dies out. I am not sure what you mean by "PyPy follows the Requires-Python metadata setting". Where is that setting and how would a python implementation read it? |
@mattip It's a metadata setting, set by |
@mattip Quick followup: you can get pip to lie about the Python version here: https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-python-version Or you can just ignore it altogether here: https://pip.pypa.io/en/stable/reference/pip_install/#cmdoption-ignore-requires-python |
I had an idea about this earlier. Instead of a new option, we could change the default CIBW_BUILD from
This means:
What I really like about this is that if a user explicitly says I also don't think this would conflict with existing uses of What do you think? |
Having EOL Python versions doesn't occur that often, though? 2.7 is a special case, and 3.5 is kind of an exception (I surprised it hasn't been ejected from
But I kind of like this thought, yes. What about having |
With universal and the new archs, How about making it an error to run cibuildwheel with nothing selected after BUILD and SKIP applied, and then we could make the error message smart if someone writes a selector that would have worked if Requires-Python was the only reason it came up empty? Then |
This is why I stopped pushing for left to right selection and |
Just a thought; how about we don't plan on changing the default? cibuildwheel then will always try to build all Pythons it supports, unless Requires-Python is set (in pyproject.toml or setup.cfg, we can't pull Footnotes
|
Ah, dang, I knew it was too good to be true. Anyway, I think we're all on the same page about reading So maybe I'm coming around to the Playing with docs...
(I started writing the above and then saw your docs in the PR @henryiii, so I've combined a few of your ideas in there too)
Haha, I was also thinking about the same thing. Respecting But, as previously discussed, this option would still give us the ability to deprecate old versions of Python, simply by changing what we assume when we can't find Python-Requires. |
It looks like that's already what's happening in #536! |
cp36*
now in build and that doesn't have to change unless they want to split based on it, see the final comments. macOS 11 considers "universal2" to be auto.CIBW_MIN_PYTHON
flag, with the usual variants (and maybe command line flag? Don't know what the policy is for that). If it is not set, we read the value from PEP 621's location if set (eventually), and for now use 2.7 (27?) if not set. For CIBW 2.0, we can change the default to 3.6 (36?), but users could get at least 2.7 back by manually specifying this. This is mostly so we can keep the defaults "nice", while also supporting the full range that we can support. From 2.0 on, we raise the default minimum to always match the official Python EOL. feat: support brace expansion in BUILD/SKIP #527{}
syntax, which I love using on the shell (partially because I'm a fish user and tab completion works correctly when using it, so it's perfect for moves and such).cp{27,35}*
seems like it should work. Ve can activate the BRACE and NEGATE flags; this is simpler than my example above (basically just BUILD + SKIP), and is already well documented so we don't have to try to teach people how to use it, we can just point at this. Eventually, if this works well, we could push users away from the SKIP flag.ARCH/MIN_PYTHON are about telling cibuildwheel what you are interested in supporting, and is something we can adjust over time to "ideal" defaults, unless a user overrides them, in which case they specifically want that thing. With SKIP, which is in this category sort of, user overrides blend CPython/PyPy, Python version, and OS-ARCH, so we can't control each default separately without the new variables. BUILD is more about telling it what "this" job is trying to build out of the total allowed set.
Further; I propose we split the unreleased "special" value for "arch" into three special values:
"native"
: The native architecture (always one value)."auto"
: Produces the native architecture + 32bit on 64bit non-macOS systems, or + universal2 on macOS. Basically "everything you can run tests on". This would be default, just like auto for CIBW_PLATFORM. I think this was first proposed by @mayeut ?"all"
: Every known architecture, 3 archs on macOS, 2 on Windows, and 5 on linux, currently. Could grow in the future.This makes universal2 fit in nicely, and provides a simple way to recover classic behavior. If you want to run on macOS 11 but want the old behavior, just set
CIBW_ARCHS_MACOS: native
. That would work nicely if you have separate runs on hypothetical Apple Silicon runners someday. You could also usenative
if you use thearchitecture
setting on the setup-python action, which is currently non-trivial to implement (due to different spellings on Windows and Linux).And "all" lets you put all the work on build selectors; users would have to be aware that the "all" set could grow in future versions if new manylinux archs were added.
Native example:
This is probably best worked on after #484 goes in.
Originally posted by @henryiii in #516 (comment)
The text was updated successfully, but these errors were encountered: