This is interesting, thank you for sharing that perspective, it’s not something I’d considered. I guess, in my head, pip had already evolved into more of a generic term with the advent of pip-tools, pipx, pipenv, etc. But, I get that those all build on pip (unlike uv), and perhaps you’re not comfortable with those either.
2 Likes
I think of pip-tools (and pip-run) as things that would have been pip plugins if that were an option. But equally, as they aren’t, I think the names are clumsy and would change them if I could. I tend to dislike pipenv on so many levels that the fact that it uses pip in its name is the least of my worries 
And pipx is a funny edge case where I probably should dislike it, but I don’t really mind, in practice.
Naming is hard.
16 Likes
One reason I can understand wanting to work away from everyone’s eyes is wanting to stay focused on a task that’s extremely difficult to execute well. Because the moment you start taking into account everyone’s point of view, your development speed slows dramatically.
12 Likes
@charliermarsh Thanks for the thoughtful responses here. Are you planning to be at PyCon again this year? If so, I think you (or someone working on uv) would find the packaging summit as a valuable place for discussions and to better understand this ecosystem and best practices for contributing back.
12 Likes
I’ll be there! As will other folks from the team. Would be happy to attend.
10 Likes
I think continuing to engage with the community and standards as you have been doing is a good start!
Note:
I do not speak with any authority or affiliations with the PyPA, but I am a professional Python user and an active participant in the broader Open Source Python community. I successfully encouraged my day-job to sponsor the PSF and I have also sponsored in a personal capacity.
From my perspective (again, purely subjective, I don’t really want to derail this conversation to a “vote for your favorite missing feature” discussion), there are 3 large quality-of-life improvements that have been lingering on the horizon for a very long time and that could potentially benefit from a little push.
1. PEP 708 – Extending the Repository API to Mitigate Dependency Confusion Attacks
Implementing this would initially require a PR to pypi/warehouse and then there are some other items mentioned in this PEP itself. I believe this to be important because Security should be the default, there have been an increase of these kinds of attacks, there are many existing users who are vulnerable to the attack and uv has users that are now asking for the --extra-index-url feature, it would be prudent to perhaps explore if a secure implementation can be provided instead.
- Estimated time and effort from Astral - Medium
- Estimated time and effort from community (PyPA, PyPI, pip etc) - Undefined
2. PEP 643 – Metadata for Package Source Distributions
This is already (hopefully) on-track towards an ecosystem rollout. There is a warehouse PR that is hopefully close to being merged. At which point hopefully Build Backends and Installers (including uv) can leverage it. This will provide (mostly) static metadata for sdist and help resolvers/installers avoid downloads or invoking a Python interpreter in (hopefully) many cases. There are still scenarios where metadata is Dynamic, but there is a general nudge towards static metadata for the majority of scenarios. Perhaps in some far future, removal of Dynamic metadata is the Python Packaging equivalent of removal of the GIL 
- Estimated time and effort from Astral - Low. Implement support in uv where sdist metadata is available.
- Estimated time and effort from community (PyPA, PyPI, pip etc) - Low. Work on PyPI appears to be very close. I was made aware that
hatchlinghas support for it (Build Backend). There is a long-tail of work required by other Build Backends and Installers, but I hope that I’m being fair in my estimate. It may vary for different tools, but broadly the work is decentralized and could be delivered by projects independently when there is time and resources available. I don’t wish to suggest for a moment that its easy or quick for these projects however.
3. No PEP (yet) - Lockfile standard
This got very close in my opinion with PEP 665 – A file format to list Python dependencies for reproducibility of an application. Ultimately it was rejected because of lack of sdist support. You are already engaged with @brettcannon here, which is fantastic. Im hopeful that the next attempt can be successful.
- Estimated time and effort from Astral - Undefined
- Estimated time and effort from community (PyPA, PyPI, pip etc) - High. Mostly because it’s uncertain and very difficult in most cases to author a coherent standard that aligns everything sufficiently.
I believe that delivering these 3 items will materially improve the ecosystem. They will improve security, installation/resolution speed, and reproducibility for both uv, pip and users of other future or existing tools.
12 Likes
#3 is actively being worked on by Brett as we speak actually! He was invested for a few months in the resolver part but now that UV happened has switched to coming up with such a lock file format that will please all audiences this time i.e. source distributions will be a consideration.
Based on a comment in Discord it sounds like he has a clear idea about what to do and I am quite hopeful
7 Likes
(People may already be aware, but note that the warehouse PR for this one is authored by an Astral employee! Albeit it builds on an earlier PR by another contributor.)
6 Likes
The initial implementation of PEP 708 is to the installers (pip, etc), which is to reject installing packages that could be obtained from more than one index unless the user has provided some tool-specific override.
The next step is for third-party indices to support the additional metadata allowing the installers to determine whether the name collisions are intentional without the user having to specify it.
As far as I’m aware, nothing actually has to change in PyPI itself, since that would be the one that is tracked, not one that will track anything else.
I think there’s some confusion about the status of PEP 708 then, at the very least from me. I’ve not seen any installer attempt to start implementing and the discussion in the PEP 708 thread appears that the Pip maintainers are waiting on… something?
But we should probably take that discussion there.
2 Likes
PyPI needs to support the “alternate locations” data. I don’t know how critical that is in practice[1], but “PyPI having an implementation” is required to move the PEP to “accepted/final” status.
Someone to do the work, basically. @dstufft was originally hoping to do it, but personal issues and general workload as a PyPI maintainer seem to have got in the way of that.
i.e., how many projects will actually define alternate locations ↩︎
4 Likes
Thanks for the reminder, I’ve filed Implement PEP 708 · Issue #15431 · pypi/warehouse · GitHub to capture this.
5 Likes
Hey all,
Ruben from prefix.dev here.
We’ve given it a good thought and decided to start the integration of uv into pixi.
So we’re letting rip Rest In Peace ( maybe it was in the name all along )
We’ll take what we’ve learned and use it in our uv integration and probably make contributions to uv along the way. We’ve already had a conversation with Astral and we think all parties will benefit from not having more implementations.
You can read more details in our blogpost about it here: Adopting uv in pixi | prefix.dev
36 Likes
I would just like to add, I know rip never had as much community attention that uv has had, but I really appreciate the effort put into it.
Just a month ago I was considering when it might be worth switching my own workflows from using pip to rip.
Both rip’s and uv’s resolvers have very similar performance characteristics. They both are generally fast but both slow down or fail to resolve in the same places. So there are still the same problems to solve.
I hope the uv project is really able to help out pixi, and vice versa.
13 Likes
I think this is because it was released as a component rather than a CLI tool. You can’t rip install anything. But I was excited to see it because it seemed like a path toward bridging the packaging divide between PyPI and conda-forge. I hope that uv will still allow progress there, I think it’d be a big win.
5 Likes
Rye has been announced prior to Armin’s update, just more quiet. 
1 Like
Fantastic update on this. Support has landed on PyPI and the first distributions with sdist metadata have been uploaded.
There’s more to be done from Build Backends and Installers, but hopefully they’ll be incentivised now.
4 Likes