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.

Reply via email to