I saw that, hoping it goes well as all of the other tools we've tried have
fairly significant issues.
On Sat, 13 May 2017 at 12:55, Christian Schwarz wrote:
> Side note: There is an ongoing effort to build a dependency manager
> that aims at becoming part of the official Golang toolchain:
>
> ht
Side note: There is an ongoing effort to build a dependency manager
that aims at becoming part of the official Golang toolchain:
https://github.com/golang/dep
Cheers,
Christian
signature.asc
Description: This is a digitally signed message part
Agree with previous sentiments, and:
On 17-04-18 10:59 PM, Christopher Hall wrote:
You should use built in golang vendoring to ensure these
dependencies, as their is no guarantee that someone won't update the
library port and your app would break, so doing that is very fragile
Currently the GH
would have to have as many versions of each lib as there are
> > > consumers, or nearly as many.
> > >
> > > Further, best practice in the Go community is for Go apps to
> > > vendor all their dependencies and almost all apps do that. This
> > > is the r
t;> Further, best practice in the Go community is for Go apps to vendor all
>> their dependencies and almost all apps do that. This is the reason most
>> Go apps use different versions of it's libs.
>>
>> So to me, packaging Go libs doesn't make sense and I thi
ibs to even be useful, we would have to have as many
> versions of each lib as there are consumers, or nearly as many.
>
> Further, best practice in the Go community is for Go apps to vendor all
> their dependencies and almost all apps do that. This is the reason most
> Go apps use di
consumers, or nearly as many.
> >
> > Further, best practice in the Go community is for Go apps to vendor
> > all their dependencies and almost all apps do that. This is the
> > reason most Go apps use different versions of it's libs.
> >
> > So to me, packa
t; all their dependencies and almost all apps do that. This is the
> reason most Go apps use different versions of it's libs.
>
> So to me, packaging Go libs doesn't make sense and I think we should
> remove the Go libs from ports.
>
> Existing ports which use the Go
are consumers, or nearly as many.
>
> Further, best practice in the Go community is for Go apps to vendor all
> their dependencies and almost all apps do that. This is the reason most
> Go apps use different versions of it's libs.
>
> So to me, packaging Go libs doesn't make
that. This is the reason most
Go apps use different versions of it's libs.
So to me, packaging Go libs doesn't make sense and I think we should
remove the Go libs from ports.
Existing ports which use the Go libs should be updated to not use the Go
lib ports by doing one of thes
10 matches
Mail list logo
