From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 159AB138334 for ; Tue, 17 Sep 2019 14:10:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6BB5CE08F9; Tue, 17 Sep 2019 14:10:32 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 161B0E08ED for ; Tue, 17 Sep 2019 14:10:32 +0000 (UTC) Received: from linux1.home (cpe-66-68-48-101.austin.res.rr.com [66.68.48.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: williamh) by smtp.gentoo.org (Postfix) with ESMTPSA id ADA4834B2D2; Tue, 17 Sep 2019 14:10:30 +0000 (UTC) Received: (nullmailer pid 5803 invoked by uid 1000); Tue, 17 Sep 2019 14:10:28 -0000 Date: Tue, 17 Sep 2019 09:10:28 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Cc: mgorny@gentoo.org, zmedico@gentoo.org Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules Message-ID: <20190917141028.GA5659@linux1.home> Mail-Followup-To: gentoo-dev@lists.gentoo.org, mgorny@gentoo.org, zmedico@gentoo.org References: <20190916141719.12922-1-williamh@gentoo.org> <20190916141719.12922-2-williamh@gentoo.org> <2f70ef66-63d7-0359-17a0-e517979f700d@gentoo.org> <20190916183500.GB27855@whubbs1.dev.av1.gaikai.org> <20190916220048.GA28491@whubbs1.dev.av1.gaikai.org> <35b14362c4ac77ffac5ff753becebd094dd994c3.camel@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <35b14362c4ac77ffac5ff753becebd094dd994c3.camel@gentoo.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Archives-Salt: f57aa507-f6fa-41ce-a648-310e40cbb7e9 X-Archives-Hash: 55ed0b5eafb55e675938e5711ce308c2 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2019 at 07:36:07AM +0200, Micha=C5=82 G=C3=B3rny wrote: > On Mon, 2019-09-16 at 17:00 -0500, William Hubbs wrote: > > On Mon, Sep 16, 2019 at 11:50:12AM -0700, Zac Medico wrote: > > > On 9/16/19 11:35 AM, William Hubbs wrote: > > > > On Mon, Sep 16, 2019 at 11:01:38AM -0700, Zac Medico wrote: > > > > > For packages that I maintain, I'd prefer to continue using EGO_VE= NDOR to > > > > > even with packages using go.mod. I hope that this go-module.class= will > > > > > not preclude this sort of usage. For example, the latest go-tools= ebuild > > > > > uses EGO_VENDOR together with GOFLAGS=3D"-mod=3Dvendor": > > > > >=20 > > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3D8cc6d40113= 9526e2f9a6dbadbd31f0ff2387705f > > > >=20 > > > > Can you elaborate on why you want to keep EGO_VENDOR? > > > >=20 > > > > The "go mod vendor" command above downloads all the correct versions > > > > of the dependencies and puts them in the vendor directory, so I'm n= ot > > > > sure why you would need the EGO_VENDOR variable. > > >=20 > > > EGO_VENDOR eliminates to need to generate and host monolithic tarballs > > > containing vendored dependencies. It's more space-efficient in the se= nse > > > that each vendored dependency is stored in a separate tarball, so > > > multiple ebuilds can share the same tarball if the version of a > > > particular vendored dependency has not changed. > >=20 > > I see what you are saying, but I haven't yet found a way to generate > > these separate tarballs that I'm comfortable with. Also, thinking about > > this, there will be many more tarballs on our mirrors if we store one > > dependency in each tarball than if we generate vendor tarballs that > > contain all dependencies for a package. > >=20 > > I would consider this an enhancement to the eclass if you still feel > > that we need it, but let me get the eclass into the tree first then we > > can work on that. > >=20 >=20 > That sounds like a bad idea. If there are any potential enhancements > that can happen, I'd rather see them happen before there's a bunch of > ebuilds using the eclass in the wild, and potentially limiting possible > changes. Like I just said on IRC, it would have been better if you responded in terms of discussing the enhancement itself. The main blocker for me is that EGO_VENDOR is basically the same information as go.mod, but it isn't quite the same format. You can get close with "go list -m all", but EGO_VENDOR doesn't automatically handle imports that start with things like golang.org/x or gopkg.in; you have to manually fix those, and you would have to do that every time. That seems to be a lot of work for little gain. William --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCXYDpTwAKCRBuVBb0MMRl ONeiAJ9oyGx3VuReQFOUw6pMgPzadfFi0QCfe6894cXBeRZmBJhkMXmK3UJ0msw= =A7+F -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1--