Date: Tue, 18 Apr 2017 13:09:22 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: Christopher Hall <christopherhall.hsw@gmail.com>, Steve Wills <steve@mouf.net> Cc: ports@freebsd.org Subject: Re: Packaging Go Libs Message-ID: <CAHEMsqY0hFh7Lm%2B%2BgHwtF0XfkHaGFk7kMp1-AcfjJ7Of3CAy5A@mail.gmail.com> In-Reply-To: <20170418103350.433498f4@arria.bitmark.lan> References: <e34c63fd-8b3d-3bb3-7375-58631b33a50a@mouf.net> <20170418103350.433498f4@arria.bitmark.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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 On Tue, 18 Apr 2017 at 03:34, Christopher Hall < christopherhall.hsw@gmail.com> wrote: > Hello Steve, > > On Mon, 17 Apr 2017 10:20:20 -0400, Steve Wills <steve@mouf.net> wrote: > > > Hi, > > > > I'd like to propose eliminating packaging of Go libs. > > For my own go application I use the ports mechanism to specify specific > versions of dependencies and it would only have been tested with those; > if forces to use an older version it would likely fail as the APIs on > some libs have changed quite a lot. > > So I personally see no need to have any go dependencies in the ports > tree. I currently like the idea of having all the go dependencies > statically linked and only few external "C" libs as dynamic links as it > makes packaging and deployment very quick. > > > > > Almost every Go app is developed with a different version of any given > > lib than what another Go app might use. Forcing a Go app to use a > > different version than what upstream might have chosen is error prone > > at best and likely to produce a build that's unsupported upstream. So > > for the packaged libs 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 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 these, in priority order: > > > > * Converted to using vendored deps included with the package source if > > possible (preferred) > > * Fetching the versions of deps specified by upstream (in the case of > > vendor.json) > > * As a last resort (deps are not included nor versions specified > > exactly) fetching versions of deps available at the time of upstream > > development > > > > Further, documentation should be added to the Porters Handbook saying > > that we don't package Go libs and portlint should be updated to check > > for installing files in GO_SRCDIR and GO_LIBDIR (exceot lang/go*). > > > > For reference, here's the list of Go lib ports that I found at the > > moment: > > > > archivers/go-compress > > databases/gomdb > > databases/gosqlite3 > > databases/levigo > > databases/radix.v2 > > databases/redigo > > devel/go-bayesian > > devel/go-cobra > > devel/go-codec > > devel/go-cpuid > > devel/go-crc32 > > devel/go-faker > > devel/go-form > > devel/go-go.uuid > > devel/go-goregen > > devel/go-hashicorp-logutils > > devel/go-json-rest > > devel/go-logrus > > devel/go-metrics > > devel/go-nuid > > devel/go-pflag > > devel/go-protobuf > > devel/go-raw > > devel/go-runewidth > > devel/go-slices > > devel/go-sql-driver > > devel/go-uuid > > devel/go-yaml > > devel/goprotobuf > > net/go-amqp > > net/go-geoip > > net/go-httppath > > net/go-httptreemux > > net/go-nats > > net/go.net > > security/go.crypto > > security/goptlib > > textproc/go.text > > www/go-fasthttp > > www/webgo > > > > Does anyone have any objection or reasoning why this doesn't make > > sense? > > > > Thanks, > > Steve > > > > > -- > Best Regards. > Christopher Hall. > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHEMsqY0hFh7Lm%2B%2BgHwtF0XfkHaGFk7kMp1-AcfjJ7Of3CAy5A>