Packaging Go Libs

[Steve Wills]

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 <steve at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 638 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20170418/4469d7bf/attachment.sig>