Hacker News new | ask | show | jobs
by cxr 1003 days ago
> npm is a fairly standard package manager, much like many others

Yes.

> They both happen to use the word and concept of "version" but to mean different things.

Right. I think I covered that adequately.

> And vendoring doesn't work for actual packages published to the package repo.

What?

> If they vendored dependencies then every dependency would be duplicated always, defeating the very purpose of a package manager!

Yes. Alternatively:

Please clearly articulate the purpose of a package manager (in the sense of the term when it's used to describe npm and others). See if you can work it out so that you can state it in the form of a testable hypothesis (i.e. ideally in quantitative terms like MBs/GBs of disk space used, or network transit, or time to fetch—or anything that you think accurately reflects what you consider to be the value proposition that npm fulfills and which we can use to evaluate it in scenarios where it would or would not be a good fit).

1 comments

Man, this isn't hard.

The purpose of a packages manager is to allow me to describe the packages and versions that my own package depends on, and download compatible versions of those dependencies and their transitive dependencies in such a way that dependencies are shared and that my runtime can use them.

npm does that, as does Cargo, Pub, Gems, pip, etc.

> Man, this isn't hard.

Well, you ducked the question—and what you did say isn't particularly illuminating to anyone who is already familiar with npm and cargo—so it's not at all clear at this point that you're right about that. (Your overall comment actually reads a lot like the sort of thing that I mentioned at the top of this thread: "non-specific appeals to the necessity of it all [...] vague arguments [...] they manage to work in a slight that's designed to paint you, implicitly or explicitly, as a junior".)

I'll ask again: what is the value proposition of npm-like package managers in quantitative terms? Your hypothesis should be falsifiable, if not testable.

If you're having difficulty, we might start here:

> in such a way that dependencies are shared

Why?

"Your hypothesis should be falsifiable, if not testable"

Seriously? There are not strange requirements, and you're ducking the issue by trying to force a pseudo-scientific dialog on this. There are language semantics in play, among many other considerations that I'm sure you're well aware of.

But I don't need to convince you, you're already convinced. Have fun.

> Seriously?

Yes, seriously.

> There are not strange requirements

Huh?

> you're ducking the issue

I am? How? (What is the issue I'm ducking?)

> There are language semantics in play, among many other considerations that I'm sure you're well aware of.

What?

> I don't need to convince you, you're already convinced.

I don't get it. (What am I already convinced of?) You said this wasn't hard. So why does it seem that way?