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 B9D501382C5 for ; Thu, 17 Dec 2020 21:14:41 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E42ABE096F; Thu, 17 Dec 2020 21:14:38 +0000 (UTC) Received: from smtp.gentoo.org (dev.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 99848E0965 for ; Thu, 17 Dec 2020 21:14:38 +0000 (UTC) Message-ID: <4f6bfc9910c010bb589443f6d727d97df7483926.camel@gentoo.org> Subject: Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Thu, 17 Dec 2020 22:14:32 +0100 In-Reply-To: References: <20201211231744.1078574-1-floppym@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.2 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-Transfer-Encoding: 8bit X-Archives-Salt: d98b49b3-fcf8-4f8b-b944-fcdb128c0408 X-Archives-Hash: c87e566a67cfd5ae51fce27681f414f1 On Thu, 2020-12-17 at 16:08 -0500, Mike Gilbert wrote: > On Thu, Dec 17, 2020 at 3:50 PM Mike Gilbert > wrote: > > > > On Thu, Dec 17, 2020 at 3:38 PM William Hubbs > > wrote: > > > > > > On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: > > > > On Sat, Dec 12, 2020 at 9:09 PM William Hubbs > > > > wrote: > > > > > > > > > > On Sat, Dec 12, 2020 at 04:25:48PM -0500, Mike Gilbert wrote: > > > > > > On Sat, Dec 12, 2020 at 3:48 PM William Hubbs > > > > > > wrote: > > > > > > > If both /usr/bin/python and /usr/bin/python3 are going > > > > > > > away, the best > > > > > > > choice would be to add functionality to python-exec or > > > > > > > eselect python to tell us > > > > > > > the path to the default python interpretor. Once we know > > > > > > > that we call it > > > > > > > directly. > > > > > > > > > > > > I don't think they are "going away". There is a USE flag on > > > > > > dev-lang/python-exec that makes them optional, and I think > > > > > > it will be > > > > > > forcibly enabled for the foreseeable future. > > > > > > > > > > > > > Please do not apply this patch to meson; I think we can > > > > > > > figure something > > > > > > > out that is better. > > > > > > > > > > > > I think installing a small script to help translate > > > > > > arguments from one > > > > > > format to another is a reasonable solution. > > > > > > > > > >  I think we should look at the eclass to see if we can > > > > > provide functions > > > > >  that can be used by consumers to handle this. > > > > > > > > I don't really understand what you mean by this. I am > > > > converting one > > > > internal bash function into an external script so that its > > > > python > > > > dependencies can be better defined and managed. > > > > > > What I mean is, ebuilds should not be calling _meson_env_array at > > > all > > > since it is defined and documented as an eclass internal > > > function. > > > > > > I would like to know more about what the gallium-nine-standalone > > > ebuild > > > is doing and why it needs to call a meson.eclass internal > > > function. > > > > > > On the other hand, if _meson_env_array is meant to be called by > > > ebuilds, > > > we need to rename it and improve the documentation for it in the > > > eclass. > > > > I do not really care about gallium-nine-standalone and its abuse of > > the private _meson_env_array function. That's an issue that should > > be > > separate from the change I am proposing. I am only touching the > > ebuild > > because my patch removes the _meson_env_array function and I want > > to > > avoid breaking the ebuild. > > > > > > > Also, I don't think your script will run if native-symlinks > > > > > is disabled since in > > > > > that setting /usr/bin/python would not exist. > > > > > > > > python_doscript updates the shebang before installing the > > > > script. > > > > > >  Ok, I didn't know python_doscript does this, but couldn't we > > > just > > >  change line 129 in the eclass to "python3 -c ..."? > > > > No, that will not help in any way. > > > > > > > I question the value of the native-symlinks  use flag on > > > > > python-exec > > > > > unless there is a way to query the path of the default python > > > > > interpretor. > > > > > > > > Regardless, I don't see how that makes my solution a bad thing. > > > > It > > > > ensures that the code will be executed by a > > > > known/support/tested > > > > version of python. > > > > > > > > > > I'm not sure how useful the script is as a command, so I don't > > > think it > > > should be installed that way, but I do want to hear more about > > > this, > > > both from you and chewi. :-) > > > > I don't see any reasonable way to make it work otherwise. If you > > have > > no better suggestion, please refrain from further comments. > > I gave it a little more thought, and I suppose we could use "eselect > python show" to get a valid python interpreter. I'll put together a > patch for that. > Do you want all meson packages to depend on eselect-python? -- Best regards, Michał Górny