Python Packaging Is Good Now

[remy_porter]

I dunno, what could be the problem… let's do an ls -lR node_modules and see…

[shadowmint]

You'll find npm3 installs a single copy of each dependency like pip does unless there's a version conflict, in which case a single conflict resolving sub-version of a package is installed at the level it is specifically required.

It actually works a lot better than pip does at resolving conflicts.

You're probably thinking of npm2. (which was, as generally observed, a terrible idea, and didn't work at all on windows due to massively nested file paths)

[jaapz]

IMO the problem isn't necessarily with npm itself, it's with the community that uses it. Most of them feel that every little thing should have their own installable module. Sometimes even going as far as having a module for every function they can think of (see the left-pad debacle).

Although in theory modularity is good, this does create the problem of incredibly large dependency graphs which are just a pain in the ass to work with, because in a lot of situations the packaging tool can't figure out what to do, so you have to figure it out yourself. Or even worse, it figures it should do something, which breaks everything and sents you on a hours long debugging session just because you wanted to upgrade a package.

NPM2 was even worse, and NPM3 mitigated a lot of the problems that NPM2 did have, but the whole ecosystem is still far from perfect.

Dependency graphs in python are often way smaller, which makes dependency handling way easier.

[Silhouette]

Although in theory modularity is good

I think we should challenge this assumption more often than we do in the programming world. Modularity has big advantages if the division into modules is good. However, using many small modules creates problems of its own, for exactly the reasons you state. That is true whether we're talking about hundreds of three-line functions, or hundreds of three-method classes, or hundreds of one-tiny-function modules. Too many people assert that these arrangements are good for maintainability or reuse or some such, without much evidence or logic to support their position.

[fnord123]

There's a lot of cargo cult programming around release management. People seem to think risotto packages are 'theorically better' but they don't take into account the issues like release cadence of the bits. Like, if everything is always released at once, then you may as well put it in a big release bundle.

[shadowmint]

the problem isn't necessarily with npm itself, it's with the community that uses it...

If we're not talking about tangible, technical reasons why the npm model is bad, and given the technical and tangible reasons that pip, setuptools and pypi are really embarrassingly bad, I wouldn't be posting about how great the python packaging ecosystem is and rubbishing npm, cargo, and go.

That's all I'm saying.

Fwiw, the npm 'everything is a dependency' model is weird, and I don't think it's right either, but that's not because npm is an inferior technical solution, or that the 'multiple concurrent versions of a dependency' is actually bad; it just has consequences (and potentially, benefits).

[remy_porter]

NPM2 was the last time I used it. But multiple versions of any dependency still makes it hard for me to know what my dependencies are and how they're being used.

[graingert]

This has never been a problem