To me it feels like a reasonable tradeoff between security, configuration, and UX: variant plugins are totally opt-in, and the instructions for users of pytorch are still pretty simple: install the correct variant plugin[2] before you install pytorch.
The fact that plugins are a thing you add to your installer, not to your environment is an important distinction.
I didn’t get any answer last time, and it doesn’t seem like this is in the Rejected Ideas section of the current PEP, so I’m curious what’s wrong with it.
mentioning this not to toot my horn but to emphasize that I agree it’s a reasonable solution ↩︎
which they can write themselves, or standardize on with others in the same space ↩︎
of course I would want this to be something that applied to all installers, and that example might not even be how pip would want to expose it.
I should have found a way to qualify that or spell it out more and was only using that as an example shorthand for demonstrating that we could still reasonably do something like this without it requiring significant work for the end users that this is meant to help.
I think the main issue is “pretty simple” is not something I’d agree with for main target users that benefit from this work. This is less intended for specialized/experienced users and more for beginners where any opt-in/extra instructions quick path to support questions/confusion.
At the moment, pytorch.org gives you a multiple-choice interface with five (!) different selectors so it can construct the proper install command. That’s not even covering installers besides pip: uv, conda, etc are not represented there. It seems like uv install-plugin gpu-selector && uv install pytorch would be better than what they have?
The answer shouldn’t be to make everything have less secure defaults at a point in time where supply chain vulnerabilities are one of the highest value targets right now.
I also don’t understand who these users are that they have bleeding edge hardware, where a 3 month delay on vendoring hardware detection is fine, but just updating a centralized set of properties is not, how such users wouldn’t be willing to run one extra command once (they shouldn’t need the hardware detection to be updated once their hardware is detected right?) and why these users are elevated above the security concerns.
There’s no bleeding edge hardware requirement. Many laptops have gpus where variants would affect wheel selection. CPU variants similarly don’t require some new fancy hardware to be relevant. The users I’m thinking of is any casual person exploring ML. Like someone at a conference. Or someone that does code but mostly in another language. Or just a less technical manager/pm.
The point about pace of hardware change has been an argument for this PEP. I don’t understand who the target user is who would be all of these things (unable to run an extra command, on brand new hardware that needs to be supported, but that a 3 month delay is fine because it won’t be updated until their package manager handles it, but that we’re not okay just standardizing these if a delay is happening anyhow), and it does require all of these things for a less disruptive solution to not work.
But it doesn’t really matter if these users have GPU acceleration[1] out of the box? Their casual exploration will work just fine on their CPU. It might be nicer for them to have acceleration, but that’s a very small benefit that probably isn’t worth any downsides in e.g. security or maintenance burden.
I think you are underestimating the speed difference. No gpu vs gpu is often order of magnitude difference that even for toy datasets it affects user experience. If it was like 1.5x or 2x sure it may not matter much. When it can be 10x+ even beginners it’s important.
I understand the speed difference perfectly well–I’ve used these libraries myself. And I’ve run them on CPU while developing, because I didn’t need that acceleration (and it often wasn’t available to me anyway).
That use case doesn’t justify anything like this amount of complexity. edit: But there are other, more compelling justifications for this PEP! They just lend themselves more to tradeoffs like the one above.
Probably, but I would argue that even if I would be totally fine with a temporary “opt-in behavior like the Free-Threading feature”, any solution that permanently (meaning not temporarily) requires explicit opt-in is the worst UX we can probably offer (beside having no variant support at all). And I would personally virtually prefer any other proposal/solution than this.
Users do not read documentation. Nobody read the documentation of every single package.
You might install package B transitively through package A doing [installer] install A which also pulls B, and you would need to know B is a variant and need a special behavior.
From my perspective this is not an acceptable permanent solution. This would force the worst user experience possible and make the feature very difficult to use and consequently rarely used.
They must be reading some documentation. How does anyone install anything?
But I don’t think any of this is a need, right? You don’t need to know that there are variants available, unless you care about them. If you pull in a dependency without installing the relevant selector first, you simply get a default.
If a package doesn’t have defaults, then anything depending on it needs to include the variant-selector step in their documentation.
I’m not at all in charge of making decisions, but if the position of the authors is “it must be this way or not at all” then “not at all” seems like the more likely outcome.
Kind of. I don’t think there’s a previous equivalent to the *-variants.json file, and the PyPI FAQ really only implies immutability for sdist and wheel artifacts. Which makes sense since (AFAIK) those are the only types of files that PyPI currently hosts. There’s no inherent reason why PyPI has to treat *-variants.json files as immutable.
Well, name me a PEP that’s been airtight and perfect on its first Post-History thread on DPO . It’s a valid call-out to address explicitly in an update[1]. The PEP should describe the requirement, provide recommended behavior for PyPI, and non-normative suggestions for alternative indexes.
In the same vein as above, I don’t think the PEP should be prescriptive in telling tools what they have to implement. It can specify behaviors and protocols that are required for interoperability, and outline a set of issues that tools need to consider, but I don’t think it wants to be in the business of dictating to tools what they must do.
For example, pip could decide that it doesn’t want to play in the variants space. I think it would be a mistake to cede that “market share” other tools, but it’s a perfectly valid decision. People who need variants will make other tool choices, and people who don’t won’t care.
You cite having no variant support at all as the worst UX but that is the status quo. It is important to understand that most discussions like this do not end up with an accepted (and implemented!) PEP. There is a risk here that you push for everything and walk away with nothing.
It seems obvious to me that this would have to be explicit opt-in to begin with regardless of what the long term plans are. It is better in these discussions to push for something that is achievable, that delivers immediate value, and that can be built on in future rather than making it all or nothing.
I said above:
My expectation would be that if there are opt-in variants then some projects will upload them and some people will use them. When that becomes well established a question like “should installers vendor/depend on/implement the x86_64_plugin package?” becomes much more concrete.
I imagine that installer maintainers would then look at the code in x86_64_plugin and see that it is not so bad like it’s stable, doesn’t change much, obviously not a security risk etc. I imagine that when they can see them in real life they would view the GPU plugins in a very different light from the CPU ones. Right now they are being asked to accept all of those things together but without even being given a concrete list of what is being referred to.
Sigh. Once again, I feel like the goalposts are shifting.
Is the PEP insisting that (possibly after some transition period) variant plugins will be executed with no opt-in? Where is that stated?
The PEP says
All the tools that need to query variant providers and are run in a security-sensitive context, MUST NOT install or run code from any untrusted package for variant resolution without explicit user opt-in.
The only way I can reconcile this with your statement above is that you expect all plugins to somehow become “trusted” over time. And yet that’s not stated anywhere in the PEP, meaning that it’s left as a tool decision, which I can confidently say, means that tools won’t just magically decide to trust plugins (I know I’ll strongly resist that happening in pip). In a world where supply chain attacks are a serious threat, and packaging security is a high profile issue, I fail to see how that is a reasonable position to take.
Maybe uv can accept this position - they seem happy to create their own implementation of the key providers, and to support them directly. But pip doesn’t have the funding or resources to do that, and the PEP is so vague that there isn’t even any certainty what such an implementation would even look like.
Sure. But users learn what to do by being told, or by asking on the web, or by asking an LLM. They can find out how to set up their installer to install pytorch. For pity’s sake, we’re talking about people who are planning to experiment with pytorch - how the heck do you think they’ll manage to do that if they aren’t willing to read any documentation???
This simply doesn’t feel like a good faith argument
And anyway, this is what the “How to teach this” section is about. The PEP itself says “The primary source of information for Python package users should be installer documentation”, and “The installer documentation may also be supplemented by documentation specific to Python projects, in particular their installation instructions”.
You cannot make those statements in the PEP and then claim “users do not read documentation”.
I think the intention from the wording in the PEP is that trust is an install-time question. You don’t trust a plugin that has been suggested by some package but has not been installed yet. Hypothetically:
$ pip install foo
...
Need to install gpu_plugin
Do you trust gpu_plugin [y/N]?
If you say yes then you install the plugin and once installed it is trusted and can be used in future.
Let’s say that we’ve agreed on the specification for representing variants, in the file names, in the index API, in the additions to wheel metadata. And we’ve agreed to the basic semantics of how and when variants are resolved, and what that means for installing variants by compliant installers. Now we have the ability to interoperate.
Now we’re “just” working out the recommendations and tradeoffs for how installers invoke variant providers so that they can calculate which variants to install when they detect that variants are available. Each tool can then work through their own decisions about which recommendation to implement, if any.
I think it’s important to separate the basic protocol and interoperability standards from the individual tool behavior recommendations, at least as much as possible.
Agreed. And I’m happy if that gets added in the next revision[1]. I apologise if I implied anything other than that.
Although I don’t see why the suggestions for other indexes have to be non-normative. You can quite reasonably make firm requirements, which indexes must adhere to if they want to claim that they “support variants”. ↩︎
I agree 100%. The problem right now is that the PEP doesn’t do that. If you’re suggesting that there will be an update to the PEP that strips it right down to just the “ability to interoperate” items you describe in your first paragraph, then I’d welcome that. Let’s keep tool behaviour and UI recommendations out of the PEP, or at the very least in appendices that are clearly marked as being nothing more than suggestions.
But at least some of the PEP authors seem pretty vested in particular UI or implementation choices for certain tools (i.e., pip). To the extent that I find it almost impossible at times to identify what’s an interoperability requirement, and what’s (at this point, frankly rather unwelcome) UI advice for pip. To give a specific example, what’s the protocol/interoperability requirement driving the suggestions that pip vendors plugins, or that pip ensures that pip install pytorch works without needing extra options to enable plugins?
. It’s a valid call-out to address explicitly in an update