On Sat, Jan 7, 2017 at 9:19 AM Jacek Furmankiewicz <jace...@gmail.com> wrote:
> What happens when you have multiple projects, all with different versions > of the same library ( some projects are newer, some older, some more > maintained than others, etc). > > Would you need a different GOPATH per project? > That in particular is a problem that vendoring is meant to address, as well as the dependency/packaging group that is currently working to solve this in an official manner. Yea, if you are basing it on the filesystem, you would have explicit checkouts, which wont work between different projects. You could use a combination of that and a vendoring solution but not check the vendor location into the repo. Then you would end up with a manifest (i.e using Glide) which specifies the versions, and be able to run an update to pull down your specific versions into the untracked vendor location. > > > On Fri, Jan 6, 2017 at 2:15 PM, Justin Israel <justinisr...@gmail.com> > wrote: > > > > On Sat, Jan 7, 2017, 9:04 AM Jacek Furmankiewicz <jace...@gmail.com> > wrote: > > Hi Daniel. > > I participated in the great Go survey on dependency management a while > back and raised these concerns there. > I read the summary of that once it was completed and was kinda > disappointed to see that none of this points seem to be getting addressed > or even acknowledged as a problem. > > > https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/?utm_source=golangweekly&utm_medium=email > > Sure, govendor can force using a private repo for a library. Not it does > not force it for all its dependencies, so you're back to the same clunky > management of every single library with a custom path/repo for every single > one of them. > > The core issue is Go's insistence on using the VCS path of a library as > its import path, unlike any other language out there. > There is no way to create a central repo with all packages and point to > it. Even Rust got this right on day one, with crates.io. > > > Go, as a language, does not insist on the import path being the vcs path. > It is only a string, for flexibility reasons. It is the choice of the go > tool to treat the import path as a vcs path. Other tooling can do what it > wants. > > Would the multiple GOPATH setup work for you? This means you are not > putting 3rd party code into the repo or giving wide open access to get any > library you want. You could only import libraries that exist on the managed > GOPATH. Then it just becomes a developer setup requirement to have the > appropriate GOPATH set in the environment. > > > I understand this was one of the opinionated decisions the Go creators > made in the early days, > but the end result is that we simply cannot even touch Go as a potential > language. > > I don't think this is a side effect they envisioned when they made this > decision. :-( > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
