3 ms·

Go's model is pretty good. This is why there's just a single $GOPATH and every package has exactly one location on disk, so even if 100 dependencies use the sa

by NateDad 12y ago

Go's model is pretty good. This is why there's just a single $GOPATH and every package has exactly one location on disk, so even if 100 dependencies use the same subdependency... you only have to update one spot if it needs a patch. And again, this only needs to be done at development time. It's baked in when you compile, and from there on, deployment is just a file copy of your binary. No dependencies during deployment.

notduncansmith 12y ago
Maybe I'm missing something, but this seems like a bad idea to me. What if projects are relying on differing versions of the same package? What if two developers collaborating on the same project have different versions of that dependency installed? Sure, it's space-efficient, but disk is cheap, and developer hours are expensive. I certainly wouldn't want two employees burning man-hours trying to figure out why some app is behaving differently on their respective machines, only to fix the problem and unwittingly break another project in the most expensively subtle of ways. I'd really like to think I'm missing something though, I certainly don't presume to be more insightful than the collective Go team.
- ploxiln 12y ago
  There's a philosophical disagreement here. It's true, developers are expensive. But I think it's a fallacy that what's less efficient for a computer is better for a developer. The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. They need new tools to help them get a handle on the huge number of modules. That's more expensive than a system kept more "under control".
  - notduncansmith 12y ago
    > I think it's a fallacy that what's less efficient for a computer is better for a developer. I don't think that was ever said; I claimed that trading disk space for developer hours is a good trade-off in this case. > The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. I don't believe this is the case. When developing an app (as opposed to a library) it's considered a best practice to check your node modules into source control, ensuring that there's never a mismatch between installed dependencies on developer machines. If you don't want to do that, you take what comes - but even before I picked up on that, I never ran into issues even when collaborating with 5+ developers. You just need to make sure your package.json locks your versions appropriately.
- NateDad 12y ago
  So, in theory, any particular import path should be stable. There are no "different versions" of the same import path. A different version would be a different path. So, for example, github.com/natefinch/lumberjack is an import path. When I wanted to change the API, I have to put my project at a different import path so I don't break projects that use this version. I could just make a new github repo called lumberjack-v2 and that would work fine. Of course, reality and theory don't always see eye to eye, and the Go community realizes this. That's why there are several community-made tools to help out. The most well-respected one is godep, which has the ability to pin revisions on your dependencies. That is, it'll look at the git commit hash (or equiv for hg/bzr/svn) for every repo that you depend on, and record it in a file in your repo. It can then reset those dependencies to those specific hashes. Then all members of your team just need to use godep to make sure they're all using the exact same git commits for all dependencies. Bam - now you're insulated from someone updating a dependency with breaking changes, and your team can test new revisions and decide when they want to start using them. Godep has a second function that lets you copy all your dependencies into your repo and renames all import statements to reference the copied paths. This is an even more extreme version of the above, which not only insulates you from changes in dependencies, but also insulates you from those dependencies disappearing entirely.
  - notduncansmith 12y ago
    Godep is definitely a good tool. One thing that gives me pause, though, is that this functionality is not built into `go get`. Failing to put hard versioning into the canonical package manager seems short-sighted to me. I'd much prefer that over something like the race detector.

by NateDad 12y ago

notduncansmith 12y ago

Maybe I'm missing something, but this seems like a bad idea to me. What if projects are relying on differing versions of the same package? What if two developers collaborating on the same project have different versions of that dependency installed? Sure, it's space-efficient, but disk is cheap, and developer hours are expensive. I certainly wouldn't want two employees burning man-hours trying to figure out why some app is behaving differently on their respective machines, only to fix the problem and unwittingly break another project in the most expensively subtle of ways. I'd really like to think I'm missing something though, I certainly don't presume to be more insightful than the collective Go team.

ploxiln 12y ago
There's a philosophical disagreement here. It's true, developers are expensive. But I think it's a fallacy that what's less efficient for a computer is better for a developer. The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. They need new tools to help them get a handle on the huge number of modules. That's more expensive than a system kept more "under control".
- notduncansmith 12y ago
  > I think it's a fallacy that what's less efficient for a computer is better for a developer. I don't think that was ever said; I claimed that trading disk space for developer hours is a good trade-off in this case. > The npm-style dependency tree enables and encourages much more complexity, which developers then have to deal with when debugging or deploying. I don't believe this is the case. When developing an app (as opposed to a library) it's considered a best practice to check your node modules into source control, ensuring that there's never a mismatch between installed dependencies on developer machines. If you don't want to do that, you take what comes - but even before I picked up on that, I never ran into issues even when collaborating with 5+ developers. You just need to make sure your package.json locks your versions appropriately.
NateDad 12y ago
So, in theory, any particular import path should be stable. There are no "different versions" of the same import path. A different version would be a different path. So, for example, github.com/natefinch/lumberjack is an import path. When I wanted to change the API, I have to put my project at a different import path so I don't break projects that use this version. I could just make a new github repo called lumberjack-v2 and that would work fine. Of course, reality and theory don't always see eye to eye, and the Go community realizes this. That's why there are several community-made tools to help out. The most well-respected one is godep, which has the ability to pin revisions on your dependencies. That is, it'll look at the git commit hash (or equiv for hg/bzr/svn) for every repo that you depend on, and record it in a file in your repo. It can then reset those dependencies to those specific hashes. Then all members of your team just need to use godep to make sure they're all using the exact same git commits for all dependencies. Bam - now you're insulated from someone updating a dependency with breaking changes, and your team can test new revisions and decide when they want to start using them. Godep has a second function that lets you copy all your dependencies into your repo and renames all import statements to reference the copied paths. This is an even more extreme version of the above, which not only insulates you from changes in dependencies, but also insulates you from those dependencies disappearing entirely.
- notduncansmith 12y ago
  Godep is definitely a good tool. One thing that gives me pause, though, is that this functionality is not built into `go get`. Failing to put hard versioning into the canonical package manager seems short-sighted to me. I'd much prefer that over something like the race detector.