Hmm.
I can’t really imagine detection. That seems like it would have required building something in to the recommended subprocess approach ahead of time.
As far as deprecation goes, I similarly can’t see a way for Pip itself to say anything about it, and have it actual directed at the right people. So that just leaves the documentation, and praying the right people read it.
Aside from that, there’s the reasoning that if people expect python -m pip in a new subprocess to work, then they’re expecting pip to exist in the current environment. Since Pip isn’t part of the standard library, these users therefore have pip as a dependency (even if they aren’t using it as a library), and should declare it. That would at least allow pip install theirapp, run from a different Pip, to notice that the destination environment lacks Pip and install it. (And when run from the environment’s Pip, everything works already and there’s no more to do.) That does defeat the purpose of the zipapp, but those developers (and their users) weren’t planning around the zipapp anyway. The situation hasn’t really gotten worse for them - there’s just a roadblock that prevents things from getting as much better for them as ought to happen.
But.
Notable from that discussion:
So maybe what’s needed is a tool that actually does have that API - and is minimal and focused. Or maybe just the library for it, never mind making a(nother) competitor to Pip. (Or maybe in the far future, Pip could use something like that internally.)
Overwhelmingly, as far as I’m aware, people[1] do these tricks because they’re distributing an application with optional extras, and want the user to be able to obtain the extras at runtime (as opposed to only supporting theirapp[feature] at the initial installation, or expecting the user to understand and wrestle with Pip manually). One good example of this that I’ve run into is Manim.
So these are cases where sdist support is probably much less important on average: you wouldn’t be doing this in the first place if you had the kind of users who could deal with an sdist installation potentially failing[2]. Caching is probably also much less important: it’s relatively unlikely the user has the dependency in cache, and users who do would already have the skills to manage the environment manually. The main tasks are to resolve dependencies, grab wheels, figure out the right directory, and do the unpacking. Those could all be part of a developer toolchain. (And the last part is, to my understanding, already covered by installer.)
That is, outside of cases like IPython/Jupyter/Spyder where the project is itself a Python development tool. ↩︎
Although actually, the Manim stack will try to pull in some huge AI-related stuff depending on exactly what you’re trying to do. I’ve been trying to build a much more lightweight approach to video rendering. But that’s another story… ↩︎