7 ms·

> For all practical purposes dependency management for programming languages is a solved problem It's obviously not solved satisfactory.

pcwalton 9y ago
Yes, it is. Everything can be improved, but I see very few complaints with Cargo, and, most importantly, not complaints that would be solved with minimal version selection. (Most complaints I see are about the lack of package namespacing.)
- crtc 9y ago
  > I see very few complaints If you live in a filter bubble (survivorship bias).
- weberc2 9y ago
  I agree that Cargo is awesome and I would be happy to see Go follow suit, but I interpret "package management is solved" to mean "the industry has standardized on a single scheme". There does seem to be convergence in this space, but it's a relatively new phenomenon.
  - sagichmal 9y ago
    Yes, the industry has absolutely standardized on a single scheme: manifest plus lock as separate declarations, SAT solver, single dependency version per compilation unit.
    - weberc2 9y ago
      If that's the case, it's a pretty recent development. Python and JS didn't have this until very recently. Yeah, Go is a bit late to the party, but hardly worth the dramatic criticism in this thread.
    - clhodapp 9y ago
      That may be what things are converging on but in my opinion, any system that imposes a "single dependency version per compilation unit" policy is not a "real" dependency management solution. That approach creates a tremendous amount of friction because it pretty much ensures dependency hell if there are transitive dependencies with separate release cycles (and there very much should be able to be). Edit: I just realized that we may have a different definition of "compilation unit". If you mean "single program" then my point stands. However, if you just meant some sectioned-off part of the program, then I think the drawbacks of that are far less. Basically, I think that it is useful to be able to have access to multiple versions of a datatype (e.g. if you want to write a converter from old -> new) but that use case is far more fringe.
      - steveklabnik 9y ago
        To be clear, Cargo fits the latter definition; you can't depend directly on two different versions of a package, but you can transitively.
      - XorNot 9y ago
        As a sysadmin I object to the notion that old to new conversions are a "fringe" use-case. Pretty much all my coding (I'm a "devops" sysadmin-type) is exclusively "I need to wrangle all versions of thing 1 into a type of thing 2 or between several versions of thing 1". If backwards compatibility is important, then letting me use multiple versions side-by-side in the same modules easily is damn important.
    - ngrilly 9y ago
      No, it's hardly a standard. It's just a common approach. The article presents another approach which differs on the three points you mention: manifest plus lock as separate declarations, SAT solver, single dependency version per compilation unit. And I think what Russ proposes is a really interesting tradeoff in the design space.
      - sagichmal 9y ago
        It is the _defacto_ standard and has been for many years. It is what's expected by the absolute and vast majority of software developers.
- curun1r 9y ago
  One of the ways I'm hopeful that cargo can improve in this area is through the work being done on rust-semverver. If crates.io can either determine semver compliance or, perhaps, deny releases that are not properly semantically versioned, it would give cargo more license to select a single version to satisfy diamond dependency graphs. Those diamond dependency graphs are one of the ways that package management is famously very much unsolved.
stouset 9y ago
Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. I swear I should put together a list of these instances.
- jjuel 9y ago
  Do you have proof that the Go team has not looked at any other dependency management approaches or considered ones from other languages?
  - stouset 9y ago
    Obviously I don’t, but the available evidence — to me, anyway — points to this being a cultural reality in the golang ecosystem. I left the language years ago, but the steady stream of articles of the form “Why go doesn’t need $x” followed by innumerable comments, articles, and blog posts by people struggling with the lack of $x, followed by the go core team (due to the completely foreseeable consequences of not having $x) begrudgingly adopting $y, which is supposed to (but doesn’t actually) obviate the need for $x… I’ve reached my own conclusions, and I’m finding more and more people who are leaving the ecosystem with those same conclusions. I believe that Go excellently solves problems that Google has. I don’t believe it solves many problems that most other users have, even though it might seem like it at the outset.
    - pjmlp 9y ago
      Wait until they finally cave in to generics being one of the top requests on Go surveys and bring something to Go following that same design process.
- mseepgood 9y ago
  > Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. Actually it's pretty clear that they did their homework.

pcwalton 9y ago

Yes, it is. Everything can be improved, but I see very few complaints with Cargo, and, most importantly, not complaints that would be solved with minimal version selection. (Most complaints I see are about the lack of package namespacing.)

crtc 9y ago
> I see very few complaints If you live in a filter bubble (survivorship bias).
weberc2 9y ago
I agree that Cargo is awesome and I would be happy to see Go follow suit, but I interpret "package management is solved" to mean "the industry has standardized on a single scheme". There does seem to be convergence in this space, but it's a relatively new phenomenon.
- sagichmal 9y ago
  Yes, the industry has absolutely standardized on a single scheme: manifest plus lock as separate declarations, SAT solver, single dependency version per compilation unit.
  - weberc2 9y ago
    If that's the case, it's a pretty recent development. Python and JS didn't have this until very recently. Yeah, Go is a bit late to the party, but hardly worth the dramatic criticism in this thread.
  - clhodapp 9y ago
    That may be what things are converging on but in my opinion, any system that imposes a "single dependency version per compilation unit" policy is not a "real" dependency management solution. That approach creates a tremendous amount of friction because it pretty much ensures dependency hell if there are transitive dependencies with separate release cycles (and there very much should be able to be). Edit: I just realized that we may have a different definition of "compilation unit". If you mean "single program" then my point stands. However, if you just meant some sectioned-off part of the program, then I think the drawbacks of that are far less. Basically, I think that it is useful to be able to have access to multiple versions of a datatype (e.g. if you want to write a converter from old -> new) but that use case is far more fringe.
    - steveklabnik 9y ago
      To be clear, Cargo fits the latter definition; you can't depend directly on two different versions of a package, but you can transitively.
    - XorNot 9y ago
      As a sysadmin I object to the notion that old to new conversions are a "fringe" use-case. Pretty much all my coding (I'm a "devops" sysadmin-type) is exclusively "I need to wrangle all versions of thing 1 into a type of thing 2 or between several versions of thing 1". If backwards compatibility is important, then letting me use multiple versions side-by-side in the same modules easily is damn important.
  - ngrilly 9y ago
    No, it's hardly a standard. It's just a common approach. The article presents another approach which differs on the three points you mention: manifest plus lock as separate declarations, SAT solver, single dependency version per compilation unit. And I think what Russ proposes is a really interesting tradeoff in the design space.
    - sagichmal 9y ago
      It is the _defacto_ standard and has been for many years. It is what's expected by the absolute and vast majority of software developers.
curun1r 9y ago
One of the ways I'm hopeful that cargo can improve in this area is through the work being done on rust-semverver. If crates.io can either determine semver compliance or, perhaps, deny releases that are not properly semantically versioned, it would give cargo more license to select a single version to satisfy diamond dependency graphs. Those diamond dependency graphs are one of the ways that package management is famously very much unsolved.

stouset 9y ago

Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. I swear I should put together a list of these instances.

jjuel 9y ago
Do you have proof that the Go team has not looked at any other dependency management approaches or considered ones from other languages?
- stouset 9y ago
  Obviously I don’t, but the available evidence — to me, anyway — points to this being a cultural reality in the golang ecosystem. I left the language years ago, but the steady stream of articles of the form “Why go doesn’t need $x” followed by innumerable comments, articles, and blog posts by people struggling with the lack of $x, followed by the go core team (due to the completely foreseeable consequences of not having $x) begrudgingly adopting $y, which is supposed to (but doesn’t actually) obviate the need for $x… I’ve reached my own conclusions, and I’m finding more and more people who are leaving the ecosystem with those same conclusions. I believe that Go excellently solves problems that Google has. I don’t believe it solves many problems that most other users have, even though it might seem like it at the outset.
  - pjmlp 9y ago
    Wait until they finally cave in to generics being one of the top requests on Go surveys and bring something to Go following that same design process.
mseepgood 9y ago
> Only because the golang core team seem to insist on reinventing every wheel either without considering prior art, or at least without considering why prior art went with a particular approach. Actually it's pretty clear that they did their homework.