4 ms·

I agree that it is not trivial but the ruby bundler project seems to manage it reasonably well, why can't go? Mind you ruby also has a central repository in th

I agree that it is not trivial but the ruby bundler project seems to manage it reasonably well, why can't go? Mind you ruby also has a central repository in the form of rubygems which allows for this kind of versioning. Go, lacking the same thing, relies on people just entering github URLS which seems insane to me but could work I guess if everyone agrees to tag their projects using semantic versioning where appropriate. Then you could do something like person/project@v1.2.3 Mind you, of any of the companies on the planet I could think of that has the resources to to create, manage and maintain a rubygems equivalent for go, Google would be top of the list.

burntsushi 13y ago
> Go, lacking the same thing, relies on people just entering github URLS which seems insane to me but could work I guess There's no need to guess. It works. Almost the entire Go ecosystem uses it. > Then you could do something like person/project@v1.2.3 This has been suggested. But it's just a mechanism for versioned dependencies; it doesn't address the transitive dependency problem that I cited. As of right now, if you need to pin a dependency to a particular version, then you fork it yourself. I welcome this infrequent pain with open arms to the benefit of keeping the `go` tool simple. It's not like people haven't tried to setup a central repository with versioned packages [1], but it just hasn't caught on. [1] - http://www.gonuts.io/ http://www.gonuts.io/
- rurounijones 13y ago
  > There's no need to guess. It works. Almost the entire Go ecosystem uses it. For a given definition of "works". Personally speaking, my "good" has not been met but of course, each to their own. The "Fork it if you want version x" workaround also would not satisfy me. Google has the resources, reach and authority to easily setup a central repository. If they did then I would not be surprised to see people start using it like CPAN and rubygems. You say you do not want the go tool to become complex but there is no reason the dependency management side of things cannot be done with a separate tool to keep things segregated. The current tool seems to roughly match the ruby 'gem' command (albeit with-out a central repository). I am surprised google has not created an analogue of the ruby 'bundler' gem with its 'bundle' command.
  - burntsushi 13y ago
    > You say you do not want the go tool to become complex but there is no reason the dependency management side of things cannot be done with a separate tool to keep things segregated. Yes. I addressed that.

burntsushi 13y ago

> Go, lacking the same thing, relies on people just entering github URLS which seems insane to me but could work I guess There's no need to guess. It works. Almost the entire Go ecosystem uses it. > Then you could do something like person/project@v1.2.3 This has been suggested. But it's just a mechanism for versioned dependencies; it doesn't address the transitive dependency problem that I cited. As of right now, if you need to pin a dependency to a particular version, then you fork it yourself. I welcome this infrequent pain with open arms to the benefit of keeping the `go` tool simple. It's not like people haven't tried to setup a central repository with versioned packages [1], but it just hasn't caught on. [1] - http://www.gonuts.io/ http://www.gonuts.io/

rurounijones 13y ago
> There's no need to guess. It works. Almost the entire Go ecosystem uses it. For a given definition of "works". Personally speaking, my "good" has not been met but of course, each to their own. The "Fork it if you want version x" workaround also would not satisfy me. Google has the resources, reach and authority to easily setup a central repository. If they did then I would not be surprised to see people start using it like CPAN and rubygems. You say you do not want the go tool to become complex but there is no reason the dependency management side of things cannot be done with a separate tool to keep things segregated. The current tool seems to roughly match the ruby 'gem' command (albeit with-out a central repository). I am surprised google has not created an analogue of the ruby 'bundler' gem with its 'bundle' command.
- burntsushi 13y ago
  > You say you do not want the go tool to become complex but there is no reason the dependency management side of things cannot be done with a separate tool to keep things segregated. Yes. I addressed that.