feat: add --only

[henryiii]

Closes #1087 by adding a --only arg. Closes #1262. By providing an alternative that only uses the wheel identifier.

[joerick]

Hmm. I'm thinking more about this and I wonder if perhaps --build should override both CIBW_BUILD and CIBW_SKIP from environment/config. There seems something weird about the user doing explicitly cibuildwheel --build 'pp38-manylinux_x86_64' but that selects zero identifiers because there's a CIBW_SKIP=pp* in the environment. Perhaps --build should override both build & skip from environment and config. What do you think @henryiii ?

[joerick]

Ah, in fact the issue might be deeper than that, for development machine use. This comment raises another potential confusion, which is that cibuildwheel --build 'pp38-manylinux_x86_64' wouldn't even work at all on Windows/Mac, because we require the --platform flag too, which feels redundant - cibuildwheel --build 'pp38-manylinux_x86_64' --platform linux.

That makes me think that maybe we should have a flag that's more designed around the 'testing locally' use-case... and that it should override all the build selector arguments --platform, --archs, CIBW_BUILD and CIBW_SKIP. That way, you can just grab an identifier from your build logs or the docs and run a build. e.g.

--build-one IDENTIFIER
    Just run one build, as specified by IDENTIFIER. Intended to be used for
    local testing - all other build selection options and arguments are ignored
    if this flag is set.

Names could be --build-one, --build-only, or just --build...

[henryiii]

--target=<...> or --local=<...> or --only=<...> or --identifier might be options? Given it is merging several things, not just BUILD, and selector expressions are not valid. Personally I'd often do CIBW_BUILD=cp310-* since I'm lazy and don't want to look up the spelling of the rest of the os/arch tag, but being able to skip --platform (and maybe --arch) would likely make it more worth while.

[joerick]

--only makes sense to me!

[joerick]

Overall structure looks good!

[joerick]

I'm curious why these delenvs are needed? Also on line 244, and 254.

[henryiii]

Because intercepted_build_args uses platform which injects it. The point of this is to see if adding something like --platform or --archs fails or some broken --only is used, but instead it will fail because CIBW_PLATFORM is set & --only is present, and passes the test for the wrong reason.

[joerick]

I've removed the coupling of intercepted_build_args from platform - it now monkeypatches all three. I'll push that to this PR so you can have a look.

[joerick]

I've just pushed a few commits. After removing the intercepted_build_args to platform coupling, I realised that CIBW_PLATFORM was causing an error when used with the --only command line option, which doesn't seem right to me (command line options should override env vars). So I wrote a test for that and got it passing.

Let me know if that works for you!

edit: just looking at these CI failures.... done

[joerick]

The CI failures are the

WARNING: Skipping page https://pypi.org/simple/xxx/ because the GET request got Content-Type: Unknown
ones.

Having seen more of this recently I investigated a little #1254

[henryiii]

That's fine with me - IMO it should be really rare to have CIBW_PLATFORM & --only together, and it's probably a mistake on the user's part if they are both there, so I'd be fine with the error, but don't have a strong feeling on it.

[henryiii]

Added only: to the Action, since I think it would replace #1262. --only "" is now equivalent to not passing only, since that makes it easier to template, and is how other options in cibw tend to work.