Hacker News Reader

Comment by matsemann | Hacker News Reader

Yeah, switched to writing python professionally ~4 years ago, and been low key hating the ecosystem. From a java and javascript background, it's mostly been npm/mvn install and it "just works". With python, there's always someone being onboarded that can't get it to work. So many small issues. Have to have the correct version per project, then have to get the venv running. And then installing it needs to build stuff because there's no wheel, so need to set up a complete c++ and rust toolchain etc., just to pull a small project and run it.

uv doesn't solve all this, but it's reduced the amount of ways things can go wrong by a lot. And it being fast means that the feedback-loop is much quicker.

View on HN

I cannot share the same experiences. mvn is a buggy mess, randomly forgetting dependencies, and constantly needing a full clean to not die on itself. npm and the entire js ecosystem feels so immature with constant breaking changes, and circular dependency hell, when trying to uppgrade stuff.

That's an issue with the packages themselves though, not with package management as a whole. You and the comment above you are talking about different things. While there's plenty of pain to be had with npm, if you have a project that used to work years ago, you can generally just clone, install and be done, even if on older versions. On Python this used to mean a lot of hurt, often even if it was a fresh project that you just wanted to share with a colleague.

For value of "years" greater than 1?

Node/NPM was a poster child of an ecosystem where projects break three times a week, due to having too many transitive dependencies that are being updated too often.

Projects breaking so frequently on npm and node is simply not the case unless you are trying upgrade an old project, one dependency per day…

This argument makes no sense. Your dependencies don't change unless you change them, npm doesn't magically update things underneath you. Things can break when you try to update one thing or another, yes, but if you just take an old project and try and run it, it will work.

Assuming the downloads still exist? Does NPM cache all versions it ever distributed?

That's always one major thing I saw breaking old builds: old binaries stop being hosted, forcing you to rebuild them from old source, which no longer builds under current toolchains - making you either downgrade the toolchain that itself may be tricky to set up, or upgrade the library, which starts a cascade of dependency upgrades.

It's not like Node projects are distributed with their deps vendored; there's too much stuff in node_modules.

You're using a different, not hosted anymore package, three times a week? That's somewhere between very unusual and downright absurd.

Yes you can find edge cases with problems. Using this as an argument for "breaks 3 times per week" does not hold.

No, I was using this as an argument for why I don't expect Node projects older than a year or two to be buildable without significant hassle.

(Also note that outside the web/mobile space, projects that weren't updated in a year are still young, not old. "Old" is more like 5+ years.)

The two things are related. If your typical project has a dependency DAG of 1000+ projects, a bug or CVE fix somewhere will typically cause a cascade of potentially breaking updates to play out over multiple days, before everything stabilizes. This creates pressure for everyone to always stay on the bleeding edge; with a version churn like this, there's only so many old (in the calendar sense) package dists that people are willing to cache.

This used to be a common experience some years back. Like many others, I gave up on the ecosystem because of the extreme fragility of it. If it's not like that anymore, I'd love to be corrected.

I don't know if it is still as fragile as you remember but if you just never update your package-lock then it is super stable as you (transitive) dependencies never change.

The non-trivial exception being if some dependecy was downloading resources on the fly (maybe like a browser compat list) or calling system libraries (eg running shell commands)

> Does NPM cache all versions it ever distributed?

Yes it does, that's the whole point. You can still go and install the first version of express ever put on npm from 12 years ago. You can also install any of the 282 releases of it that have ever been put on npm since then. That's the whole point of a registry, it wouldn't be useful if things just disappeared at some random point in time.

The only packages that get removed are malware and such, and packages which the vendor themselves manually unpublish [0]. The latter has a bunch of rules to ensure packages that are actually used don't get removed, please see the link below.

[0] https://docs.npmjs.com/policies/unpublish

IIRC there is a package whose whole point is to include everything else in its package.json and make them ineligible for unpublish.

> npm doesn't magically update things underneath you

It used to prior to npm 5 when lockfiles were introduced (yarn introduced lockfiles earlier).

I've seen mvn projects that spin like a top and others that were a disaster.

I think it's little recognized that there is a scaling limit for snapshots. If you have 20 people developing 20 projects and they are co-located in the same room with the server builds work 50-80% of the time and people think it's fine. If you're the one guy who is remote and has a slow connection, builds work 0% of the time. The problem is that at slightly different times you get slightly different snapshots that aren't compatible with each other -- it's a scaling problem because if you add enough developers and enough projects it will eventually get you.

I've worked at other places when the mvn clean was necessary every time; other developers thought this shouldn't be necessary and I was a doofus except I was able to make consistent progress like a ratchet on the project and get it done and they weren't.

Where I am now mvn is just fine, whenever it screws up there's a rational explanation and we're doing it wrong.

I'm not saying mvn or npm is perfect. But the issues they have are consistent. My coworker and I would either have the same issues or not any issues. But with python it's probably more ways of running the project in the team than there are people, all with small tweaks to get it working on their system.

Python has been mostly working okay for me since I switched to Poetry. (“Mostly” because I think I’ve run into some weird issue once but I’ve tried to recall what it was and I just can’t.)

uv felt a bit immature at the time, but sounds like it’s way better now. I really want to try it out... but Poetry just works, so I don’t really have an incentive to switch just yet. (Though I’ve switched from FlakeHeaven or something to Ruff and the difference was heaven and hell! Pun in’tended.)

A lot of Wagtail usage is with Poetry. Tends to be projects with 30-50 dependencies. It "just works" but we see a lot of people struggle with common tasks ("how do I upgrade this package"), and complain about how slow it is. I don’t have big insights outside of Wagtail users but I don’t think it’s too different.

n=1 but i've tried "manual" .venv, conda/miniconda, pipenv, poetry, and finally now at uv. uv is great. poetry feels like it's focused on people who are publishing packages. uv is great to use for personal dev, spinning up/down lots of venv, speedy, and uvx/uv script is very convenient compared to having all my sandbox project in one poetry env.

Reply on news.ycombinator.com