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? 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.