4 ms·

Would you say that that's a good thing? I'm so tired of trying to figure out which package manager is responsible for which thing and keep track of their variou

Would you say that that's a good thing? I'm so tired of trying to figure out which package manager is responsible for which thing and keep track of their various idiosyncrasies. I think nix might be the way--just have one package manager to rule them all--but I'm not aware of any language ecosystems that are leaning into this.

cogman10 3y ago
> Would you say that that's a good thing? Yup, the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. You might get lucky like Java did with maven but that's no real guarantee. > but I'm not aware of any language ecosystems that are leaning into this. Bazel does. However, bazel (AFAIK) generally does things by leaning on the existing build systems of various languages. For software, unfortunately we are in a "jack of all trades master of none" scenario. I don't think there's a one size fits all solution.
- nequo 3y ago
  > the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. To be fair, Haskell doesn't have 20. It has two.
  - cogman10 3y ago
    Just a sec, let me go create 18 more ;) But yeah, fair point. And maybe we can rely on newer languages to converge on a package manager faster than the languages of old did due to the internet.
- __MatrixMan__ 3y ago
  Did Java get lucky? I thought it was out with maven and in with gradle--though it's been several years since I've been in that world. It's just kind of awkward how they all do the same thing in slightly different ways. But not meaningfully different. They all have some kind of lock file, and they all have some kind of cache that you have to handle specially if you don't want to download the universe in CI, and they all let you specify version restrictions but each uses different files to store these things, terminology to describe them, and uses a different configuration language for you to express them. Learning languanges would be so much fun if I didn't have to learn a new package manager each time.
  - cogman10 3y ago
    The important thing that happened for Java is the centralized repository. Gradle and maven both use the maven repository standard. So you can publish a new package and either system can pull it in. This isn't as true if you talk about plugins to the build systems so it's not as if java is unscathed. However, I'd say it's a lot better situation than what exists for C/C++ ATM.
    - __MatrixMan__ 3y ago
      I'll agree that having strong consensus about the map: (Package name, version number) -> (cryptographic hash of package bits) Both is, and ought to be, table stakes for modern language ecosystems. But when it comes to tooling for hosting, fetching, installing, and contributing re: those maps, there's no reason to have each separate language community build an overlapping set of tools that solves those problems. I understand that when you have a new language, building all of that tooling is probably a fun way to flex it, but it's a bigger problem than most language communities really have the interest in to solve properly. So it ends up being a hack job every time. I'd argue that the only reason Java doesn't feel like a hack job re: packaging is that they've (wisely) solved a smaller problem. I can use pypi to install a python package with Java dependencies, but I can't (so far as I know) use maven to install a java library with python dependencies. Better would be to have some lightweight standard for mapping package names to hashes, and then decouple the hosting/trustworthyness indicating/installing/packaging concerns such that language designers don't have to worry so much about those things since they're not really language specific problems.

cogman10 3y ago

> Would you say that that's a good thing? Yup, the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. You might get lucky like Java did with maven but that's no real guarantee. > but I'm not aware of any language ecosystems that are leaning into this. Bazel does. However, bazel (AFAIK) generally does things by leaning on the existing build systems of various languages. For software, unfortunately we are in a "jack of all trades master of none" scenario. I don't think there's a one size fits all solution.

nequo 3y ago
> the alternative is a C/C++/or Haskell scenario where instead of one generally accepted "right" package manger you end up with 20. To be fair, Haskell doesn't have 20. It has two.
- cogman10 3y ago
  Just a sec, let me go create 18 more ;) But yeah, fair point. And maybe we can rely on newer languages to converge on a package manager faster than the languages of old did due to the internet.
__MatrixMan__ 3y ago
Did Java get lucky? I thought it was out with maven and in with gradle--though it's been several years since I've been in that world. It's just kind of awkward how they all do the same thing in slightly different ways. But not meaningfully different. They all have some kind of lock file, and they all have some kind of cache that you have to handle specially if you don't want to download the universe in CI, and they all let you specify version restrictions but each uses different files to store these things, terminology to describe them, and uses a different configuration language for you to express them. Learning languanges would be so much fun if I didn't have to learn a new package manager each time.
- cogman10 3y ago
  The important thing that happened for Java is the centralized repository. Gradle and maven both use the maven repository standard. So you can publish a new package and either system can pull it in. This isn't as true if you talk about plugins to the build systems so it's not as if java is unscathed. However, I'd say it's a lot better situation than what exists for C/C++ ATM.
  - __MatrixMan__ 3y ago
    I'll agree that having strong consensus about the map: (Package name, version number) -> (cryptographic hash of package bits) Both is, and ought to be, table stakes for modern language ecosystems. But when it comes to tooling for hosting, fetching, installing, and contributing re: those maps, there's no reason to have each separate language community build an overlapping set of tools that solves those problems. I understand that when you have a new language, building all of that tooling is probably a fun way to flex it, but it's a bigger problem than most language communities really have the interest in to solve properly. So it ends up being a hack job every time. I'd argue that the only reason Java doesn't feel like a hack job re: packaging is that they've (wisely) solved a smaller problem. I can use pypi to install a python package with Java dependencies, but I can't (so far as I know) use maven to install a java library with python dependencies. Better would be to have some lightweight standard for mapping package names to hashes, and then decouple the hosting/trustworthyness indicating/installing/packaging concerns such that language designers don't have to worry so much about those things since they're not really language specific problems.