Would you consider this to be a problem in the opt-in case?
If you have something like
$ pip download foo
downloading foo...
package foo needs selector bar
Run selector bar [y/n]?
then is that acceptable?
This reminds me of how manylinux played out. There was manylinux 1 in PEP 513, then PEP 571 for manylinux 2010, then PEP 599 for manylinux 2014 and then finally PEP 600 for “perennial manylinux”. It seemed that it was possible to enumerate the possibilities but then the PEP process became too much and we needed a PEP that specified a mechanism that could be extended without a PEP.
I agree that the possibilities you enumerated cover the main cases right now but I think it is bad to get into a situation where those special cases have to be hard-coded into a specification or into individual tools without a specification. This is a dynamic problem space but we also need coordination across tools. I think it is better to have an extensible but specified mechanism as is proposed here.
The tension here is between secure-by-default and maximising convenience in the common case especially for novice users. These conflicting aims are qualitatively different though:
- Secure-by-default is binary and absolute
- Convenience is a sliding scale
The proposal as specified right now maximises convenience and then concludes that secure-by-default is not possible but I think it is better to start the other way round:
- Assume secure-by-default from the outset
- Consider how to maximise convenience without compromising security.
I can imagine that the convenience starts with an opt-in prompt:
Run selector bar [y/n]?
There can also be flags like --unsafe-run-selectors. Later on there can be blessed selectors that are vendored into the installers and at this point it is appropriate to consider the particular issues for the “big packages” to maximise convenience for common user situations while still maintaining secure-by-default.
There are various comments above about the fact that existing installers will run arbitrary code because they install from sdists. With my long memory I can say that it is (or at least was) a longstanding goal since way back to when wheels were invented to abolish this. Over time we get closer to --only-binary by default being a possibility as more packages have wheels. The proposal here as it stands suggests a backwards move on this front where arbitrary code execution would be promoted as the new way of doing things for some of the most popular packages rather than being a legacy mode for older packages that is retained for backward compatibility.
Some of the packages that provide sdist but not wheel do so because they have simply not been update to provide wheels. Others have legitimate reasons for using sdist because the wheel format does not provide what they need due to lack of arbitrary code execution. It is possible that the proposal here actually solves some of those cases by providing sufficient capability in wheel installation that they can do what is needed. That might bring us closer to the possibility of --only-binary being a plausible default. I think it would be better to consider if this proposal makes it possible to move to secure-by-default rather than using the non-secure status quo to justify introducing the proposal here in an insecure way as well.
Lastly the proposal here discusses using the variant mechanism for CPU capabilities. The proposal seems perhaps inspired by a previous thread in which I suggested exactly this. I just want to be clear here that I think that micro-architecture variants like x86_64-v2 etc should really be handled as part of the CPU tag rather than through the variant mechanism that is proposed here. As a temporary or unusual mechanism variants can make sense for CPU capabilities but this should not replace efforts to improve the way that CPU architecture is represented in the main static metadata.