4 ms·

It's the same way every package manager has done this since the beginning of time.

• lucacasonato 4y ago
  Well except for NPM :D
  • SparkyMcUnicorn 4y ago
    Composer also?
• franciscop 4y ago
  Package managers end goal was the user to use the package, so it was good that they were installed globally. npm goals, as a tool for devs, includes having projects self-contained and not interfere with each other, which is pretty different goal and thus having a local node_modules has multiple advantages instead of installing everything globally. Kinda how docker or virtual machines work, but just for packages.
  • jonny_eh 4y ago
    I was under the impression that Node (and the node_modules folder) predated NPM. So NPM was just going along with the concepts laid down by Node.
• IshKebab 4y ago
  Every system package manager. There are plenty of programming dependency managers that don't use a centralised store though.
• singularity2001 4y ago
  except for rust which downloads the same package over and over again, even in the same project!
• folkrav 4y ago
  I heavily disagree with the very premise that OS package managers are solving the same problems as language-specific, development targeted dependency management solutions.
  • yamtaddle 4y ago
    Language-specific package managers also often install globally, at least by default.
    • folkrav 4y ago
      Really? I know pip does it by default if you don't use virtual envs, but that's related to how pip works - activating the venv basically swaps pip/python executables and `site-packages` to the ones in the venv directory. I admittedly can't think of another I used where that's the case (none of cargo, go mod or npm/yarn/pnpm install globally by default). I admittedly did not really try others enough to notice how they work. Still, the end-goal is not the same, IMHO. Outside exceptions (e.g. some developers not packaging their applications and making users install through `pip`/`npm install -g`, which I also really dislike), your typical end-user would not interact with language specific package managers. They're most typically used for development/deployment dependencies, not end-user installation.
      • yamtaddle 4y ago
        Go's not technically global but the path of least resistance is to use it as if it is. You'll only notice the difference on an actual multi-user workstation, or if you take extra steps to get a per-project package directory. Rubygems is usually global. The granddaddy of them all, CPAN and its cpan install tool, defaults to installing globally, in practice, on most systems. Pip, as you noted, does it. I think Maven's typically user-scoped, so not really global, but also not project-scoped like npm. Similar to Go. You can get around this in most or all cases—sometimes with options or config, sometimes with extra effort or some aliases or scripts, sometimes environment variables, sometimes with 3rd party tools—but the simplest or default mode is global installation, or at least project-global if not user-global in Go's or Maven's cases. And many of those solutions (e.g. rvm) still don't scope installation per-project by default, like npm does. At the time npm got started, especially, it was definitely an outlier in its default scope. Some others have taken its approach since, and maybe a majority of total language-specific package managers even do, these days, but adjusted for actual use in the wild, I bet NPM's by far the most-used one that operates that way, and that most of the other popular ones scope more broadly—including, often, globally—by default. That is, a language-specific package manager one runs into in the real world, in 2022, usually isn't going to scope packages like NPM does without some extra effort. Global or per-user scoping (the latter being functionally identical on any single-user machine) are more likely.