Agree. I mostly do front end in my day job, and despite JavaScript being a bit of a mess lang, dealing with npm is way better than juggling anaconda, miniforge, Poetry, pip, venv, etc depending on the project.

UV is such a smooth UX that it makes you wonder how something like it wasn’t part of Python from the start.

+1

…but we did have to wait for cargo, npm (I include yarn and pnpm here) and maybe golang to blaze the ‘this is how it’s done’ trail. Obvious in hindsight.

Ruby's bundler had already invented the correct model many years ago. It only took time for others to accept that.

Wait, a bundler? What needs to be bundled when using Ruby? Maybe this is not the same meaning as with JS bundlers. And why does a bundles manage dependencies?

It’s what it’s called https://bundler.io/

No sillier than the other various package managers.

Yeah, but unlike bundle, uv locks in your Python version and downloads that Python version as needed. It’s like bundle and rbenv combined.

Sure. That seems less important to me than the packages. As long as the language version is checked, that’s the important bit.

More importantly, migrating from npm, to pnpm, to yarn, to bun, is very nearly seamless. Migrating in the Python ecosystem? Not anywhere close.

standardizing pyproject.toml helped but it didn't go quite far enough.

Feels like you're doing it wrong if you're dealing with all of those.

"depending on the project"

You mean off the job you have to juggle all those tools? On the job that would be kind of crazy, to allow every project its own tool chain.

True.

I had to give up on mypy and move to pyright because mypy uses pip to install missing types and they refuse to support uv. In the CI pipeline where I use UV, I don't have a pip installed so mypy complains about missing pip.

Of course I can do it by myself by adding typing pkgs to requirement.txt file then what's the point of devtools! And I don't want requirements.txt when I already got pyproject.toml.

Once you get used to cargo from rust, you just can't tolerate shitty tooling anymore. I used to think pip was great (compared to C++ tooling).

Mypy doesn't install anything by default, you're probably setting the `--install-types` flag somehow.

Pyright is waaay better than Mypy anyway so I'd say they did you a favour.

I think their only big gap is the inability to alias general project non-python scripts in uv. This forces you to use something like a justfile or similar and it would be much more ergonomic to just keep it all in uv.

uv belongs to a startup. They will surely introduce some wacky monetisation scheme sooner or later.

I wouldn't get too used to it.

Maybe, but even if that is the case it's sooooo much better that even the worst case (fork when they try to monetise it) is way better than any alternatives.

> fork when they try to monetise it

To maintain a successful fork, not only are you going to need to find people who volunteer for maintaining a fork at that scale (including a large user base due to popularity), you’ll need to find skilled Rust developers, too.

That’s going to be immensely difficult.

I mean, maybe. But I'd still much rather take that risk than flagellate myself with Pip or Pyenv or Poetry.

Strong agree. The respectful act of other package managers would be consider themselves deprecated and point to uv instead.

The risk is obviously uv losing funding. I kinda hope the PSF has thought about this and has a contingency plan for uv winning and dying/becoming enshittified soon after.

If they never made any plan about how modules are installed and there is no official way… i doubt they made a plan about uv.

I think you mean packages, not modules. And actually there is site-packages, where your stuff lands when installed with pip, so there kind of is an official way. Just many tools implementing it.

It's open source. If necessary, uv can be forked and maintained entirely as OSS.

Every time people have debates over the merits of languages I always put developer environment at the top of my list. Build tools, IDE, readable stack traces. Those things boost productivity for more than concise list comprehensions or any gimmicky syntax thing. It's why Python always felt stone age to me despite have such lovely semantics.

I am sold. Sign me up.

I have never used virtual environments well -- the learning curve after dealing with python installation and conda/pip setup and environment variables was exhausting enough. Gave up multiple times or only used them when working through step wise workshops.

If anyone can recommend a good learning resource - would love to take a stab again.

Which companies run heavily (either solely or huge parts) run on Python? They should take initiative and start blogging.

Uv doesn't fix anything. The fixing that Python needs is the removal of the concept of virtual environments and fixing the import and packaging systems instead.

The only thing it does, it makes bad things happen faster. Who cares...

Well maybe "fixes" is the wrong word. It certainly fixes the bad UX caused by virtual environments.

Basically it handles the virtual environments for you so you don't have to deal with their nonsense.

But you're right it doesn't fix it in the same way that Deno did.

I totally disagree. Having a single vendor with that much power is a bad idea. If the PSF were able to focus on tooling rather than their current focus, they would be great stewards of this sort of thing. Sadly I doubt that will happen, in which case I think many options is the best approach.

> If the PSF were able to focus on tooling rather than their current focus

Well yeah maybe if the PSF were able to get their shit together it wouldn't have taken a single third party vendor to do it for them. But they weren't and it did, so here we are.