Date: Wed, 19 Apr 2017 10:59:10 +0800 From: Christopher Hall <christopherhall.hsw@gmail.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: ports@freebsd.org Subject: Re: Packaging Go Libs Message-ID: <20170419105910.3b87a7a6@arria.bitmark.lan> In-Reply-To: <CAHEMsqY0hFh7Lm%2B%2BgHwtF0XfkHaGFk7kMp1-AcfjJ7Of3CAy5A@mail.gmail.com> References: <e34c63fd-8b3d-3bb3-7375-58631b33a50a@mouf.net> <20170418103350.433498f4@arria.bitmark.lan> <CAHEMsqY0hFh7Lm%2B%2BgHwtF0XfkHaGFk7kMp1-AcfjJ7Of3CAy5A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Steven, On Tue, 18 Apr 2017 13:09:22 +0000, Steven Hartland <killing@multiplay.co.uk> 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_TUPLE method is working as it specifies exact dependency versions or specific git hashes. but we made several attempts at submodules in vendor dir but have had problems building and go get -u breaks things. I am wondering if you might suggest a tool or do any other programs in ports use such a dependency tool. Last time I searched ports tree I only saw GH_TUPLE used so I just followed that method. > 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" -- Best Regards. Christopher Hall.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170419105910.3b87a7a6>