cross-posted from: https://sh.itjust.works/post/64685863

Lots of programming languages have their own package manager, separate from the distribution or OS package manager.

Going loosely from the TIOBE index:

  • Python has Pip
  • C# has NuGet
  • Javascript has npm for Node.js
  • Visual Basic also uses NuGet
  • R has a repository of packages that can be installed by running install.packages("something") in R
  • Rust has Cargo/Crates
  • Go has the go get command
  • Swift has its own package manager swift package
  • Ruby has RubyGems
  • Java has Maven and Gradle (not sure if they are full package managers, or build automation tools with dependency resolution)
  • PHP has Composer for managing libraries and dependencies
  • C and C++ are the only exceptions I can think of, off the top of my head; libraries are managed by, and coupled to, the operating system
  • staircase@programming.dev
    501·
    2 days ago

    If you’ve ever tried using bazel, you might understand why writing a single package manager for multiple languages is a bad idea (at least, that’s why I assume bazel is so god-awful)

    • FizzyOrange@programming.dev
      1·
      7 hours ago

      It’s not that it’s a bad idea, it’s more that it’s basically impossible at this point.

      Bazel can’t use Cargo, CMake and so on for downloading & building packages because it is trying to do cross-language builds the right way - a single build graph that includes everything. No other third party package managers/build tools actually exposed their build graphs - only commands to perform builds, which are too coarse for Bazel.

      To put it simply, its necessary if you are doing things at the scale of Bazel.

      • staircase@programming.dev
        12·
        22 hours ago

        It’s been a while since I used it in earnest, so my memory is hazy enough that I can’t be specific. One of the largest pieces of work I’ve done in C++ was not writing C++, but working out how to ask bazel to build a single shared library that imports other bazel libraries. I’ve never used such a confusing and frustrating package manager. It was frequently unclear how to do things, despite the project having quite a lot of documentation.

        When I read it supports multiple languages, I had two thoughts:

        • Why? That feels like trying to write a single style sheet for both English and Mandarin.
        • That might explain why it’s so confusing. I surmised: I has to bend over backwards to support all these different languages and their different module and packages architectures. And it doesn’t manage to hide that complexity from the user.
        • onlinepersona@programming.dev
          2·
          18 hours ago

          Thank you. I didn’t expect that because I assume that packages are basically the same everywhere you go (at least in my experience). And managing them is basically solving dependency trees, then downloading files and putting them in the right place for the import system to find them.

          But my experience with programming languages is limited. I haven’t found a language that doesn’t work this way.

          • RaphaelSchmitz@feddit.org
            1·
            6 hours ago

            I got the same feeling that it shouldn’t be rocket science. Then again, I’m most experienced with C#, which is just a very clean and professional ecosystem, and I often experience that other languages can feel rough around the edges in comparison. E.g. in npm JS, different package managers create entirely different folder structures, even though the build system is 100% the same!

            So maybe a package manager for C# would be straightforward, while npm JS would require a bunch of research about what happens behind the scenes.

            And if other languages are similar to npm JS, it’s easy to imagine that your want to keep languages separated for cleanliness - but then you kinda just get a bunch of one-language-package managers in a trenchcoat, so why even bother. OR you have the same code handling it all, becoming a bit of a mess.