I've thought about that or perhaps a quick script to turn a vendor.json in the the appropriate GH_TUPLE for a port Makefile, but even that seems less necessary these days as more and more projects included a vendor dir in their source tree.
Thanks to everyone for their input, seems we all agree, so I'll go ahead with this plan. Thanks, Steve On 04/18/2017 10:24, Julien Laffaye wrote: > I agree with you. > Maybe we should provide helpers to do the "fetching dependencies" part so > that will be less cumbersome. > > On Mon, Apr 17, 2017 at 4:20 PM, Steve Wills <st...@mouf.net> wrote: > >> Hi, >> >> I'd like to propose eliminating packaging of Go libs. >> >> 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 >> >> > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" >
signature.asc
Description: OpenPGP digital signature