Packaging Go Libs

[Christopher Hall]

Hello Steve,

On Mon, 17 Apr 2017 10:20:20 -0400, Steve Wills <steve at 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.