Build wheels from sdist (separate entrypoint)#1072
Conversation
when calling like 'python -m cibuildwheel', we get errors like
usage: __main__.py [-h] [--platform {auto,linux,macos,windows}] [--archs ARCHS] [--output-dir OUTPUT_DIR] [--config-file CONFIG_FILE]
[--print-build-identifiers] [--allow-empty] [--prerelease-pythons]
[package_dir]
__main__.py: error: unrecognized arguments: --sad
With this change, we get error outputs like:
usage: cibuildwheel [-h] [--platform {auto,linux,macos,windows}] [--archs ARCHS] [--output-dir OUTPUT_DIR] [--config-file CONFIG_FILE]
[--print-build-identifiers] [--allow-empty] [--prerelease-pythons]
[package_dir]
cibuildwheel: error: unrecognized arguments: --asda
|
I'm still not very fond of this at all, especially after seeing it. It is unavailable from the GitHub action, much harder to get from pipx run, a new command to learn, all for exactly no user benefit. It has exactly the same commands, and is exactly orthogonal in primary argument - you can only run this on SDists, you can only run the original command on folders. From what I understand, this is entirely to keep the original command simple? Adding a brand new command to maintain and test likely negates that benefit. And document! Since Pip already takes folder or SDist, there's already a mental model that you can pass a folder or an SDist to a builder. If pypa/build adds SDist support, it will work the same way. From a user perspective, they are passing in the exact same arguments, the API is identical. The only difference is some relative paths - but that's already a little murky, so I think just a little documentation would cover this just fine. Something like "if you pass an SDist, all paths except Since there's no rush, can you leave this around for a week or two so I can try doing it without a new command in an alternative PR to see how bad it actually looks? At the very least, it could be split into two internal commands that have a single entrypoint (the current one) which would at least still be much better for users. But I think it can be even better. |
Sure. I did try that when reviewing #1020 which was my motivation for this approach. The problem I hit was changing the cwd to the expanded tar directory in-process meant that all the paths in options were wrong. At that point, not wanting to further complicate things, a separate process seemed a much more pragmatic solution. But maybe I missed something. Another option to avoid a new command (though it might appear slightly perverse at first blush) would be for cibuildwheel to call /itself/ as a subprocess, once it's done the expansion of the sdist. That would avoid the extra entrypoint, and keep complexity down. But the complications around relative paths remain of course. |
|
Update: will try to work on this before PyCon, but might have to be after... |
Alternative to #1020. Fixes #597.
This provides a separate entrypoint for building wheels from sdist, rather than from a source tree.
I'm using a different entrypoint because the way that command line arguments are parsed are different. This is because cibuildwheel is run with working dir as the root of the sdist, not the current working dir. That is because the docker 'project' is the contents of the sdist, and paths in options (e.g. options within pyproject.toml) should be relative to the sdist root.
The command line options
--output-dirand--config-fileare the exceptions to this - they are options of cibuildwheel-from-sdist and thus resolved relative to the working dir.Docs are still to come, but help output is: