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 CD412138334 for ; Tue, 10 Sep 2019 18:31:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A71D2E0901; Tue, 10 Sep 2019 18:31:05 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 535BDE0835 for ; Tue, 10 Sep 2019 18:31:05 +0000 (UTC) Received: from whubbs1.gaikai.biz (unknown [100.42.103.5]) (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 28CE934AFAC; Tue, 10 Sep 2019 18:31:04 +0000 (UTC) Received: (nullmailer pid 3848 invoked by uid 1000); Tue, 10 Sep 2019 18:31:01 -0000 Date: Tue, 10 Sep 2019 13:31:01 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Cc: gyakovlev@gentoo.org Subject: Re: [gentoo-dev] rfc: go 1.13 and go modules Message-ID: <20190910183101.GA3825@whubbs1.dev.av1.gaikai.org> Mail-Followup-To: gentoo-dev@lists.gentoo.org, gyakovlev@gentoo.org References: <20190909173418.GA30003@whubbs1.dev.av1.gaikai.org> <20190910083517.1877fd18@katipo2.lan> <20190909214616.GA32528@whubbs1.dev.av1.gaikai.org> <1639276.kfM2EdqyNB@ws> <20190909232142.GA500@whubbs1.dev.av1.gaikai.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="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <20190909232142.GA500@whubbs1.dev.av1.gaikai.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Archives-Salt: 03f943ff-fc68-4eec-84f8-13efe32e32e6 X-Archives-Hash: c0a0d43c093c36e807a60ea5bba8a3f2 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 09, 2019 at 06:21:42PM -0500, William Hubbs wrote: > On Mon, Sep 09, 2019 at 03:57:18PM -0700, Georgy Yakovlev wrote: > > On Monday, September 9, 2019 2:46:16 PM PDT William Hubbs wrote: > > > On Tue, Sep 10, 2019 at 08:35:17AM +1200, Kent Fredric wrote: > > > > On Mon, 9 Sep 2019 12:34:18 -0500 > > > >=20 > > > > William Hubbs wrote: > > > > > There is another option I want to try which is adding "go mod ven= dor" to > > > > > src_unpack for go packages. > > > >=20 > > > > Is it infeasible to write a tool that you execute as a maintainer, = that > > > > simulates what "go mod vendor" would do, but instead emits a list of > > > > entries for SRC_URI, and then have an eclass or something construct= the > > > > vendor dir from those? > > > >=20 > > > > That's what is available for rust stuff. > > >=20 > > > I'm not sure how feasible something like that is. > > >=20 > > > $ go list -m all > > >=20 > > > will list the dependencies of a module, but that doesn't look like it > > > can be translated into src_uri format. > > >=20 > > > You would basically have to parse go.mod exactly the way upstream does > > > it and come up with a way to download the correct versions of the > > > source. > > >=20 > > > William > >=20 > > check mail-client/aerc ebuild. > > I use "go list -m all" and manually format EGO_VENDOR string which will= be=20 > > translated into SRC_URI by eclass. > > tool is certainly possible and should be quite easy to implement. > > some manual editing will still be needed if dealing with forked package= s/ > > repos, but looks pretty straightforward. > > This is very similar approach to cargo ebuilds and it supports offline= =20 > > installs, PM checksumming and does not require packaging every single g= o=20 > > dependency as a package. >=20 > Ok, I took a quick look at this. > We will need another eclass similar to the golang-vcs-snapshot eclass, > but it doesn't need to mess with GOPATH since GOPATH isn't used by go > modules. >=20 > I will also look at go list -m all and see what comes out of it. It looks like we would also need a way to honor the GOPROXY environment variable as well. Thanks, William --jRHKVT23PllUwdXP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCXXfr3QAKCRBuVBb0MMRl OA69AJwOzksRpLeYBdZkHjT6l8gHv39/4wCgp2cPPOIxrihrujXDwZ8vn8Cp62I= =b8Iz -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--