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 7E94B138334 for ; Tue, 17 Sep 2019 05:36:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 53EA3E09CD; Tue, 17 Sep 2019 05:36:14 +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 9F48CE0950 for ; Tue, 17 Sep 2019 05:36:13 +0000 (UTC) Received: from pomiot (c134-66.icpnet.pl [85.221.134.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 6A10D34B267; Tue, 17 Sep 2019 05:36:11 +0000 (UTC) Message-ID: <35b14362c4ac77ffac5ff753becebd094dd994c3.camel@gentoo.org> Subject: Re: [gentoo-dev] [PATCH 1/1] go-module.eclass: introduce new eclass to handle go modules From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Cc: zmedico@gentoo.org Date: Tue, 17 Sep 2019 07:36:07 +0200 In-Reply-To: <20190916220048.GA28491@whubbs1.dev.av1.gaikai.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> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-YJIjidgUQ7hzp2J6dV4p" User-Agent: Evolution 3.32.4 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 X-Archives-Salt: 647a1df5-5e66-4a74-9bf8-bd13852b9355 X-Archives-Hash: efb59d8f5714183d9ec2b99ec9029263 --=-YJIjidgUQ7hzp2J6dV4p Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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_VEND= OR to > > > > even with packages using go.mod. I hope that this go-module.class w= ill > > > > not preclude this sort of usage. For example, the latest go-tools e= build > > > > uses EGO_VENDOR together with GOFLAGS=3D"-mod=3Dvendor": > > > >=20 > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3D8cc6d4011395= 26e2f9a6dbadbd31f0ff2387705f > > >=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 not > > > 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 sens= e > > 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 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. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-YJIjidgUQ7hzp2J6dV4p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAl2AcMdfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM3 NkE4NDUwOTQwOThEMjhDQzhCMjZDNTYzOUFEQUUyMzI5RTI0MEUACgkQY5ra4jKe JA5prwgA0pd/RJw+SmENBBZzMbp7czPAmX5YCQ0kYFSAUxSjmVZO05MN1JhO0JXy e1CivVTaSUyO4NRCOE6iTAamCVtY3m9hFjlwG6OJHdp6ne1/VNB0pqq7hsAzBl+T LEvAtRb4Z1/bYJOtW7vfsL3FT47LpaJ0LXSlRDlV0VLkxGF1P/vvVjRTG/9EbNeu 4WPcVelvlnLsoPdAbm9tmZqTlVXgkHoTrAZqG4XIyAMi4TCdnENc9eAeNwcqm6Jf xZyjLwcu5WbaF6J8+ZDM5N4hQkSiDrZxlf1qgDLYQAgqRhPkHPje9DiF3bl9YGM/ wAYCzBtVGuBx2p/GLPEqEe3pjn5EhQ== =WMyP -----END PGP SIGNATURE----- --=-YJIjidgUQ7hzp2J6dV4p--