Hacker News Reader

Comment by _6pvr | Hacker News Reader

> ere really shouldn't be two standard package managers for JS.

Why? Aren't there multiple package managers in many languages? SBT/Maven, Ant/Ivy/Maven, PIP/Poem(or poetry or whatever it is). What's the harm?

View on HN

IMO, npm is a breeze compared to pip. With npm you know that `npm i && npm start` will start 95% of the projects cross-platform. It allows having different subdependencies versions in a way that just works. It encourages semver but at the same time you have lock file. Is highly customizable with rc files.

Perhaps I just don't have that much experience with pip, but it feels more like a tool to install packages, then you're on your own with some makefile or python scripts with no standard setup.

npm is one of the only dependency managers I’ve seen that does more than install packages. Every other package manager: pip, bundler, composer, all do one thing and do it well. npm does everything but nothing well.

Wow, bold statement. Can you give examples of things it does wrong?

I can.

In most ecosystems, I can share package sources between a VM and a host.

npm shares mutable content (eg compiled artifacts) with package sources in `node_modules`. That breaks a ton of workflows that are common in other ecosystems.

For instance, in ruby apps using bundler, I can commit my dependencies in vendor/cache; there are no network dependencies other than fetching the source code. That makes turning code into a running server faster and more reliable.

Go supported the same thing from v1 via GOPATH (because that's how google runs their repo). Commit your dependencies and carry on (go had different shortcomings in dependency management in those days).

This feature turns things like `left-pad` from a fiasco into a non-event.

Also, it took npm years to implement a lockfile, only for most npm commands to disregard it. I used to frequently get versions other than the one I wanted. It's been ~6 years since I switched away so it may have improved since then. After my experience using npm I fundamentally do not trust the brand, and until yarn screws up I have no reason to give npm another chance.

There's nothing stopping you from running `npm` or `yarn` offline and committing the cache.

In fact, both of these package managers have had direct support for this workflow since 2016 (https://docs.npmjs.com/cli/v7/using-npm/config#offline) and 2017 (https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/) respectively.

Except that the format of the npm cache is version-specific. You would probably be better off using https://github.com/heikkipora/registry-sync instead.

`npm uninstall foo` simultaneously upgrades all the _other_ packages.

Experienced developers they are not.

Cargo from rust does more than npm and IMHO it does very well.

There are I'm sure valid reasons for doing it, but it fragments an already fragmented ecosystem. And IMHO it is ideal for there to be a first-party solution like Ruby/Bundler, Rust/Cargo, Swift/SPM, etc.

Isn't the first party solution NPM?

The first-party solution is ES Modules. Node is not Javascript.

ES Modules aren't package management though? In that ES Modules say nothing about how to get the modules in the first place, nor anything about versions. Not in any standardized way anyhow.

Solutions are defined by the problems they address, not the mechanics of how they address them, or even particularly how good or thorough they are.

Which is to say, yes, it’s painfully half-baked and riddled with inconsistencies. But that is pretty typical of JavaScript anyhow.

> Solutions are defined by the problems they address, not the mechanics of how they address them, or even particularly how good or thorough they are.

Yeah but what I mean is that as it stands you literally cannot implement a package manager based on ES Modules alone. So it’s strange to me that someone would say that ES Modules are the package management solution for JavaScript. That’s not what it is currently for. Though the relevant standards may certainly be officially extended in the future, to allow for standardized package management based on ES Modules.

No, that’s still fixating on the mechanics, not the problem. Package management is not a valuable outcome, it’s a means to an end.

In principle, ES modules do away with needing a package manager. And yes, folks are already working on the consequential gaps in capability.

The point still being, however incomplete it currently is, this is the first-party solution. Node is not JavaScript.

You mean the npm, which is maintained by npm Inc., a subsidiary of GitHub (Microsoft)? IMO, that's where the problem lies.

It still ships with node, right? So yeah.

> And IMHO it is ideal for there to be a first-party solution like Ruby/Bundler

Bundler, AFAIK, isn't first-party, its a separate team and project.

Historically, IIRC, gems wasn't even first-party

Good standard solutions are often the outcome of multiple competing efforts pushing forward, proving what works, and proving what doesn't.

Bundler is part of Ruby since 2018: https://github.com/ruby/ruby/commit/59c8d50653480bef3f245172...

But, it's irrelevant. I'm not arguing no one should make a third-party package manager, just that there should be a standard, ideally first-party one, that is good and well supported.

Languages like Ruby, Rust, Swift have recognized it is beneficial for the core project to provide a package management solution.

I cannot make any sense of how to use packages in python. So I just don't. I don't use python all that much, but if it was easy and obvious what was the right way to do it, maybe I would. But in the rare cases that I write python, I write zero-dependency code. Or maybe I download a library and just manually copy it to a file.

At least one time, I tried to get into python packages, but I recall there seemed to be about a half a dozen methods for doing it at the time. I didn't try very hard.

I think this is a bit much. Pip takes almost no time to set up and use. It ships with MacOS in fact.

As long as you only have pure python dependencies, pip is fine. Unfortunately, that's very uncommon for DS/ML python at least.

pip install numpy

pip install pandas

I'm really really tired of explaining this, tbh.

The trouble is firstly that pip will happily install conflicting versions of numpy which breaks your code.

This occurs because pip didn't check dependencies until last year, which is one of the reasons it's a terrible package manager.

Now it just gets stuck spinning it's wheels for ages and then errors out, which is better but still not good.

Conda, while really slow actually handles c level dependencies which makes it usable.

> I'm really really tired of explaining this, tbh.

So don't!

Fair.

I consider it a public service to keep mentioning this though, so that in future jobs, I don't have to explain over and over again why I don't want to use pip to "manage" our dependencies.

My experience with stuff with C-extensions (although not specifically ML packages) is that there is almost always a wheel published for them these days, so pip works just fine and I almost never have to think about if something is pure python or not.

I wish I could say I never had to think about it, though.

notice how maven appears twice in your list for anything jvm related - that's because the jvm ecosystem is mature, and there's really only 1 package manager.

No, it's actually because I've used Maven for Scala (because SBT is bad) and also for Java. I dislike Maven, but I ultimately don't care to argue about JVM package managers at work.

This is because the Maven repository format is simple: it’s a directory convention + an xml file on each directory to indicate dependencies. It’s easy to implement and host in any web server. Other tools (Ivy, Gradle, SBT) can consume it. But, in essence it’s the same with npm and yarn: both get packages from the npm registry (the common denominator is the repository format).

Reply on news.ycombinator.com