Yeah, and there is a reason why that’s not a popular idea. A wheel-distributed CPython executable would have its C dependencies statically bundled inside that wheel, which is counter-productive, footprint-wise and security-wise, and a maintenance nightmare. A conda-distributed CPython has its C dependencies provided as shared libraries by independent conda packages (just like an apt-distributed CPython, for example).
These are fundamental difference in scope and constraints regardless of whether you like it or not.
It’s not a matter of agreeing or disagreeing, it’s just a fact. pip is usable with any Python interpreter and dependent libraries, conda requires almost the entire binary dependency tree to be conda-provided.
Yes, I agree, to get on topic the point I was making is that these new tools aren’t trying to start a new ecosystem, or create new (non-)standards, and that is a success, regardless of the nuances of why conda created it’s own ecosystem.
Users have a choice of tools and increasingly better tools, which is a success.
And it appears that some of these tools have the resources to aim to tackle common Python user workflow issues such as managing package and requirement lifecycles, and manage environments, in a completely unified way. Which would be a success, because the current core packaging tools do not have the resources to handle it themselves.
I don’t think there was a direct outreach, but from reading occasionally Charlie’s tweet I suspected (95% sure) that this was an on going project for at least 6 months now So how secretly was this was done depends on the channel’s you follow I guess. That being said me personally I’m glad there’s finally a company with paid full-time employees that can pick up the packaging problem and make it better.
What stood out to me from the hacker news discussion when paired with the discussion in Why doesn't pip write installed packages to pyproject.toml? - #70 by sirosen was that it sounds like there is a fundamental difference of opinion between what I see users saying they want (a single tool that does the entire workflow process) and what I saw stated in this forum, that pip is nothing more than a bootstrapping tool.
As a result, I can’t help but welcome uv as it will address this gap allowing pip to be a bootstrapping tool.
I may have misunderstood of course, so if anyone feels I misrepresented their opinion I’m sorry, but I see this as a positive given the existing awareness around ruff in the community which can be parlayed into greater awareness about uv compared to other solutions (which may have equal or greater technical merit). Ideally projects can converge where there is shared a foundation and goal
I’d like to echo this sentiment! Y’all have implemented various improvements that I expected to be theoretically feasible but didn’t have the available time to even explore implementing (like CoW, install tree caching) - it’s great to see those theories be proven to be feasible and performant!
I’m curious about a few things as well, which I’d appreciate responses to…
How useful the standards were in building something that would transparently interoperate with existing tooling (AFAICT, that’s what it’s doing!)? Did you need to rely on looking at the existing Python implementations for various cases (since you have reimplemented lots of stuff in Rust)?
If y’all have considered collaborating with the folks over at Prefix, who are doing a slightly differently scoped work that has overlap with this (eg: using their solver instead of pubgrub-rs, sharing Rust implementations of various PEPs). It’d be useful to know if there’s a social or a technical constraint there.
More broadly, I’m glad that someone is able to spend multiple paid-developer months on building new Python packaging tools! I’ve said this elsewhere that one of the things we need is significant developer time to be invested in this space.
I share some of the concern that others have expressed earlier that this is being built by a for-profit corporation that’s taken on significant external investment, and, I am also slightly bummed out that the energy was focused on a new tool vs improving something existing --though I understand the socio-technical reasons for both of them.
Yea, I think my opinion on uv pip is gonna depend on what Astral’s stance is on this.
One danger of words like “fundamental difference of opinion” is that it sounds like your impression is that the pip maintainers aren’t interested in the existence of workflow tools. I don’t think that’s true.
But pipisn’t the place for that tooling today – as a user, it looks correct, but for the maintainers, there are some fairly major considerations (like inclusion in CPython) which make it an unsuitable place for workflow-related tooling. Maybe that will change in the future, but I can’t say I see it happening soon.
i.e. The pip folks aren’t user-hostile. They just have to contend with some of the realities of the tooling situation which a user with a wish list doesn’t need to worry about.
Regarding the tool name, would uv uvpip be too ugly? The proposed shim could then be named uvpip, which would avoid the worrying situation of a binary named pip which is not actually pip.
Along those lines, a separate command like uv-pip might work. Subcommands are fun but not necessarily the best UX (and it seems like this is meant as a stopgap, not a long-term interface). There’s precedent in the cargo family (e.g. cargo-fmt) if that makes it more acceptable
Using the name pip at all will always have the potential to confuse people, though. I don’t think confusion can be entirely avoided, though–people can get confused about anything.
This thread is so sad to read. I honestly don’t get the reactions, even a remark on the fact that a company is behind the scene. This is crazy to me, the company was literally created to support full time FOSS. What else do you want!? It’s more than just giving back a little, it’s the whole purpose of the company. Millions of dollars getting there.
Setting this aside, I understand the “fear” (my reading and personal opinion) as when Ruff came in, it all changed and tons of projects just migrated. But what people don’t say that loud is that it’s not just about being fast and Rust, etc. It’s about listening to what the users want and engaging with the community. And here Charlie has been just extraordinary. From going out to projects to help them out, implementing features we all asked and just being an awesome and kind person Like adding Ruff to SciPy was just a pleasure and Charlie was my personal reason to really push for it to replace our other linters.
Hatch shares a similar success story thanks to Ofek who has been as incredible as Charlie. The issue is that Hatch is now getting stuck and waiting for some standard to come in (as far as I understand, e.g. lockfile). But the users still have needs to fill. Something like Poetry should never have happened in the sense that the features (again e.g. lockfile) should have been added years ago now. And this is what all survey say.
So yeah, if there is no change here, I predict the same fate to pip and alike than flake8 and other linters. Which I don’t see an issue here as we all want the same thing right? Make good tools and libraries for users and we can all work together and are not obliged to die on our own projects, right?
To clarify though, I didn’t mean to say that pip maintainers dislike / aren’t interested in the existence of workflow tools, instead I meant to state that pip is not interested in being the primary workflow tool.
Fair enough about the choice of words. It felt to me as though there really were pretty stark differences though that read that way to me. I apologize for misunderstanding though.
Congrats on the launch. I think the mini explosion of tools on the back of standards is broadly inline with the commentary that has been shared by the PyPA and in these forums for many years. I don’t think it’s a bad thing. There’s too many itches for developers to scratch to try and scratch them all through a loosely organized committee.
Let tools blossom, celebrate them, support them, help them rise, help tools that fall to land softly.
I think it’s not going to be productive to talk about the various merits of how a project started or didn’t start. It’s the past and can’t change.
I think the only productive outcome from this thread might be a list of alternative names for the package installation subcommand (it’s presently pip). The uv tool authors can then decide if an alternative name is better, or if they would prefer to wait and see first.
Of that list, I like pkg - it reads well as a subcommand (uv pkg install, uv pkg list, etc.) and it’s easy to understand what it does (“pip” is only meaningful because of the history of the term in Python, it would otherwise make no particular sense to a new user).
I will admit a heads-up would have been nice for me if they knew what I was up to as I would have pivoted to focus on lock files directly/immediately instead of trying to plug the library hole for Python resolvers that has the flexibility to do stuff that uv is doing like making it easy to resolve to the oldest versions of things. But I view this more as not being engaged here (yet) more than anything nefarious or purposeful (I’m half waiting to find out someone already has a resolver in library form and I just didn’t know about it). If anything, I do hope this drives the folks working on uv to participate here and help drive various things forward for everyone’s benefit.
I’m actively working on it and I’m now going to try to pull uv in along with all the other workflow tool authors to help make sure my 2nd attempt at them gets accepted. I think I have a design that will appease the folks who wanted sdist support in some form.
Ditto… I had considered posting the same thing in this topic earlier today, but didn’t want to muddy the waters if a naming discussion is happening elsewhere.
We can also have a paint-the-bikeshed discussion about why it would be ‘pkg’ and not ‘dist’ since Python packages are distributed and installed as distributions and not packages
I’m confused by this particular example, is what uv done for it’s resolver so different to resolvo? That is also in Rust, a CDCL style algorithm, and was developed publically in this same time frame, right?
FYI I also have a private project, but in pure Python, that works on resolution for Python packages. Among other reasons I don’t want to expose it while it’s experimental, and may never make it public. Directing to the thread in general, I don’t understand the attitude against development being private until it’s decided it’s ready for prime time or for what ever other reason.
No, it’s not the same at all. The project you’re referring to was a crate called libsolv and was simply stripped out into its own project but was around for more than a year and 1/2.
I’m confused why the project heritage here plays an important distinction?
resolvo was created about 5 months ago to solve python packaging dependencies, as used by rip for Python package indexes (like PyPI) and rattler for conda indexes.
If one was looking at package resolution around October for Python package indexes and wanted to use a Rust implemented CDCL style algorithm they could have used resolvo, and without guesswork because they could have looked at how Rip was using it, and this was all public. Why would it have been important for uv to have been public at this time compared to these projects?
And as a side note, let’s not forget that for many years a pure Python implementation of pubgrub has existed in the form of mixology and it’s Poetry implementation. Which if one does not want rust dependencies may have been a more useful reference anyway
On that topic it would be interesting to find out why the uv folks didn’t build off of it. Were there technical reasons, or social or business reasons?
Right now this thread is pretty light on comments from the uv team, although I’m not sure I can blame them. I’m sure they’re busy.
My comments were based on the assumption that Astral would not want to simply implement pip’s interface (if only because I think pip’s interface is suboptimal because of compatibility constraints). In all honesty I hope their ambitions go beyond simply implementing a “faster pip”.
So how secretly was this was done depends on the channel’s you follow I guess. That being said me personally I’m glad there’s finally a company with paid full-time employees that can pick up the packaging problem and make it better. 
