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 9C371139694 for ; Mon, 10 Apr 2017 04:36:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4FBDB21C07E; Mon, 10 Apr 2017 04:36:17 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id DDA4C21C06A for ; Mon, 10 Apr 2017 04:36:16 +0000 (UTC) Received: from katipo2.lan (unknown [203.86.205.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: kentnl) by smtp.gentoo.org (Postfix) with ESMTPSA id DEE89340F43 for ; Mon, 10 Apr 2017 04:36:14 +0000 (UTC) Date: Mon, 10 Apr 2017 16:35:48 +1200 From: Kent Fredric To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Reverse use of Python/Ruby versions Message-ID: <20170410163548.7d0e5348@katipo2.lan> In-Reply-To: References: <20170410133858.4842bbb5@katipo2.lan> Organization: Gentoo X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) 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 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/2zro7TlKKZwpeA+mCt8T/an"; protocol="application/pgp-signature" X-Archives-Salt: 1594ff52-510a-4bfc-9ee1-861ef55c1e3c X-Archives-Hash: f11cae32a8b0f268b623b43707a63322 --Sig_/2zro7TlKKZwpeA+mCt8T/an Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 9 Apr 2017 22:04:13 -0400 "William L. Thomson Jr." wrote: > This has never been the case with Java. Its not a problem with C binaries either, because you have a discrete compile time, and language level interop between compiled binary forms. Meanwhile, you cannot build two parts of a given python dependency chain wi= th different pythons, nor different perls. > If package A requires version X, but B Y, then B builds with Y as its > pulled in as a dep. while A proceeds to build with X. > > Where this is different for Python, Ruby, and also Perl. They all > install files into a directory based on version. You may have multiple > copies in each, vs one. Perl does not have targets, nor does Java. Right, but this is impossible with Ruby, Python, and Perl. Perl *could* have targets, and some people think could do with it, but it and java are very much in different boats. Perl is in the same boat as Python and Ruby where in "new version of thing" means "everything must be compiled with the new target" Perl simply has a *moving* target instead of multiple concurrent targets. Essentially, with Perl we've done the effect of "Add X, Remove Y" for all t= hings. We additionally have a much better precedent than python at syntax-interop = between versions, so its more justifiable to only have the single target ( because = you practically never need an older perl "just for compat reasons", though at the rate this= garbage[1] is going, that could change one day ) If anything, Perl is only avoiding the Python problem you hate with signifi= cant amounts of heroism, and its only a matter of time before upstream force our hands i= n ways that make that heroism non-viable, and we have to dig deep and work out how the = hell to maintain concurrent targets. > The present system is a PITA for users. Fiddling with adding/removing > targets for Python/Ruby. In addition to selecting which for the system. > All these same problems exist for Java, with the exception of > installation locations as mentioned. I honestly think you're looking at the wrong problem domain to fix this pro= blem, in ways that will introduce yet more regressions and broken trees. We should have what I've been saying we should have for a while now: * Soft Options. We only have 2 types of option at present from the users perspective, "on"= =20 options, and "off" options. Portage doesn't even distinguish between who is setting them, user profile and the gentoo profiles simply flatten into a single logical profile, and then portage then demands that changes be made to this set, failing to = discriminate at all between "ok, this was the profile specified default and it needs to = be non-default for this problem" and "user doesn't actually want this, how can we avoid that" And portage then compounds this by dictating that any option changes that e= builds need must be enshrined by the user as things the /user/ wants, when in truth, th= ey're not things the user wants, they're things the ebuilds want, and the user begrudingly a= ccepts. Hence why an option of "on, but only if portage really needs it" is missing= , but needed. I would gladly set soft-targets of every python version under the sun, and = then allow portage to turn them on *as necessary*, and this would be much preferable t= o having to either a) turn them on globally and pull in stuff and waste time compiling stuff t= hat's not even getting used. b) Maintain a painful and carefully catered list of things to prevent afore= mentioned problems. In short, users need a way to discriminate "things I care about" from "thin= gs I don't care about" Currently, its just a big cluster of those things in one place, and the com= plexity is inescapably thrust into the users hands on a daily basis. 1: https://bugs.gentoo.org/showdependencytree.cgi?id=3D613764&hide_resolved= =3D0 --Sig_/2zro7TlKKZwpeA+mCt8T/an Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEPZazbI/qrFT1o9rn6FQySxNmqCAFAljrC7QACgkQ6FQySxNm qCDuOhAAztr5OJUkgXimLo0TZiTiVaupzhyn2nsXZO+S1j8UecAee1jXh9Zqzvb4 acSO6Mp/he9aD7aUAOxEEyn3pNzIMQjZVbbjnywyZtrWliFp6ani7FdCqdFW5x8m 8DdZzWTTXxWeZplKCTIOdOoAdcfVNyLoAXzW8Qm1KZg3dMc01SiwsLugc/b6oqmw hxK75fjLxg5cjBCPC95S6TSVdnbL9fSVwUa33zzf0W2vCep3T3EyUbiIYJABqqBY quGlSXoc4g/0dQEAHnyHkJMtOAvN7soNDp46hm5z0OMao5/b/QMJMCNTlRaOIKYK ZwBRU2XHlOvF0UVe/ToQX1gDXm13fCbtRk0+vkevJEjRln/nRcGV3B59Mx22FR1O oB8mnaMlrCt0Yc6sJ8HwVOJuDQSFOpeSd27NZWJ3+mMchVlHeqr8WbKdFUrzs2lQ aqYpoYRvRqHeBTDfAnZMGs0+wGxXYhz/R704CLNE9AHFljgNDhk9zC0Hre/qUuwW pmKdKo9IRUIBzL2dRb+gsyCpRhcYb8I0CMh/Omc+6jcodHd4Mk9oMOtJk+13i1e/ qSoePrpeu0nqvZEkGOU2BihxIrBB0ZILqam3DRVuv+kNE1WFYvrK0RhYufFTQ6jr I40I+Js4XKXOXifNmyN1mq6g3MKRKlWOIwqeiZk04GKMUit2c+0= =9e7p -----END PGP SIGNATURE----- --Sig_/2zro7TlKKZwpeA+mCt8T/an--