4 ms·

> 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/Po

> 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?

wilg 5y ago
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.
- imbnwa 5y ago
  Isn't the first party solution NPM?
  - inopinatus 5y ago
    The first-party solution is ES Modules. Node is not Javascript.
    - codetrotter 5y ago
      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.
      - inopinatus 5y ago
        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.
        codetrotter 5y ago
        > 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.
        inopinatus 5y ago
        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.
  - mbesto 5y ago
    You mean the npm, which is maintained by npm Inc., a subsidiary of GitHub (Microsoft)? IMO, that's where the problem lies.
  - kall 5y ago
    It still ships with node, right? So yeah.
- dragonwriter 5y ago
  > 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.
  - wilg 5y ago
    Bundler is part of Ruby since 2018: https://github.com/ruby/ruby/commit/59c8d50653480bef3f24517296e6ddf937fdf6bc 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.
pmoleri 5y ago
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.
- ezekg 5y ago
  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.
  - pmoleri 5y ago
    Wow, bold statement. Can you give examples of things it does wrong?
    - danielheath 5y ago
      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.
recursive 5y ago
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.
- void_mint 5y ago
  I think this is a bit much. Pip takes almost no time to set up and use. It ships with MacOS in fact.
  - disgruntledphd2 5y ago
    As long as you only have pure python dependencies, pip is fine. Unfortunately, that's very uncommon for DS/ML python at least.
    - void_mint 5y ago
      pip install numpy pip install pandas ??
      - disgruntledphd2 5y ago
        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.
        void_mint 5y ago
        > I'm really really tired of explaining this, tbh. So don't!
chii 5y ago
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.
- void_mint 5y ago
  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.
- diegof79 5y ago
  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).

wilg 5y ago

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.

imbnwa 5y ago
Isn't the first party solution NPM?
- inopinatus 5y ago
  The first-party solution is ES Modules. Node is not Javascript.
  - codetrotter 5y ago
    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.
    - inopinatus 5y ago
      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.
      - codetrotter 5y ago
        > 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.
        inopinatus 5y ago
        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.
- mbesto 5y ago
  You mean the npm, which is maintained by npm Inc., a subsidiary of GitHub (Microsoft)? IMO, that's where the problem lies.
- kall 5y ago
  It still ships with node, right? So yeah.
dragonwriter 5y ago
> 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.
- wilg 5y ago
  Bundler is part of Ruby since 2018: https://github.com/ruby/ruby/commit/59c8d50653480bef3f24517296e6ddf937fdf6bc 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.

pmoleri 5y ago

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.

ezekg 5y ago
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.
- pmoleri 5y ago
  Wow, bold statement. Can you give examples of things it does wrong?
  - danielheath 5y ago
    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.

recursive 5y ago

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.

void_mint 5y ago
I think this is a bit much. Pip takes almost no time to set up and use. It ships with MacOS in fact.
- disgruntledphd2 5y ago
  As long as you only have pure python dependencies, pip is fine. Unfortunately, that's very uncommon for DS/ML python at least.
  - void_mint 5y ago
    pip install numpy pip install pandas ??
    - disgruntledphd2 5y ago
      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.
      - void_mint 5y ago
        > I'm really really tired of explaining this, tbh. So don't!

chii 5y ago

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.

void_mint 5y ago
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.
diegof79 5y ago
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).