Date: Tue, 18 Apr 2017 14:08:23 -0400 From: Steve Wills <steve@mouf.net> To: Julien Laffaye <jlaffaye@freebsd.org> Cc: "ports@freebsd.org" <ports@freebsd.org> Subject: Re: Packaging Go Libs Message-ID: <a62cb1c3-428d-9d22-45e9-44c95a6020c2@mouf.net> In-Reply-To: <CAGSB0sNbnUV1w=m2acpiQt2SyafnN5csxvuRNMqDp2jborR8RQ@mail.gmail.com> References: <e34c63fd-8b3d-3bb3-7375-58631b33a50a@mouf.net> <CAGSB0sNbnUV1w=m2acpiQt2SyafnN5csxvuRNMqDp2jborR8RQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TlHAidNud0Q5a6wR480mfJwEjVLjd1esS Content-Type: multipart/mixed; boundary="cpKp3N8boojL2mS2n62GHT6LSvQR3F1Ox"; protected-headers="v1" From: Steve Wills <steve@mouf.net> To: Julien Laffaye <jlaffaye@freebsd.org> Cc: "ports@freebsd.org" <ports@freebsd.org> Message-ID: <a62cb1c3-428d-9d22-45e9-44c95a6020c2@mouf.net> Subject: Re: Packaging Go Libs References: <e34c63fd-8b3d-3bb3-7375-58631b33a50a@mouf.net> <CAGSB0sNbnUV1w=m2acpiQt2SyafnN5csxvuRNMqDp2jborR8RQ@mail.gmail.com> In-Reply-To: <CAGSB0sNbnUV1w=m2acpiQt2SyafnN5csxvuRNMqDp2jborR8RQ@mail.gmail.com> --cpKp3N8boojL2mS2n62GHT6LSvQR3F1Ox Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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. >=20 > On Mon, Apr 17, 2017 at 4:20 PM, Steve Wills <steve@mouf.net> wrote: >=20 >> 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 al= l >> their dependencies and almost all apps do that. This is the reason mos= t >> 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 mom= ent: >> >> 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 sens= e? >> >> Thanks, >> Steve >> >> > _______________________________________________ > 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= " >=20 --cpKp3N8boojL2mS2n62GHT6LSvQR3F1Ox-- --TlHAidNud0Q5a6wR480mfJwEjVLjd1esS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGjBAEBCgCNFiEEmPpBSlwqDvnP0K0N9c9isyB7G6EFAlj2VhdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk4 RkE0MTRBNUMyQTBFRjlDRkQwQUQwREY1Q0Y2MkIzMjA3QjFCQTEPHHN0ZXZlQG1v dWYubmV0AAoJEPXPYrMgexuhubsH+wVi6HDaxf+zfGiOtNho64KhFzAVPPKYdkPz R2kNI5jAy2UtkassW2mjGWlTnau5RSRskNwincrqwdomDMhFCKzFDOD2Tr8ugKzZ vV5XTQiGCpvMTH1y1offr4BWlPTcuWHFWqWCkW0FIFtHjFENLT7AQS0gZAr7T7Pr ZdNB+GBgFTM0yKnk2zdFaBooGRSnNzC/xEdMT8NlzfRRWYhUilEUuAyM6JKvi7Vm uf2OaBfzL25eaVcoG7X2kTwtImo8Yd4d0Kove9Jzs+tgYznXLmfBMMOb7tWsswoB z2+SUkQPCOQaVKk8YFf9eX9FU7kyRZpW+foAiJ+7WAlv1W1lJSM= =MKj8 -----END PGP SIGNATURE----- --TlHAidNud0Q5a6wR480mfJwEjVLjd1esS--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a62cb1c3-428d-9d22-45e9-44c95a6020c2>