Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
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
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
On Thu, 17 Dec 2020 14:38:43 -0600 William Hubbs wrote: > On Sat, Dec 12, 2020 at 09:22:06PM -0500, Mike Gilbert wrote: > > 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 knew I spoke to someone about this on IRC and turns out it was you 2 years ago. :P The ebuild needs to render flags as a Meson array and this eclass function is the best way to do it. You did not know why it was private and said to go ahead anyway but file a bug so that this situation could be improved. I admittedly didn't get around to filing a bug but I was totally prepared to deal with the fall out if it broke. Now floppym is improving the situation anyway and fixing the ebuild too. I give my thanks to him. Job done? -- James Le Cuirot (chewi) Gentoo Linux Developer pgpPbvZE71UX_.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
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.
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
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.
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
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. > > 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 ..."? > > 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. :-) William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
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. > 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. > 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.
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
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. Also, I don't think your script will run if native-symlinks is disabled since in that setting /usr/bin/python would not exist. 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. William signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
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.
Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
On Fri, Dec 11, 2020 at 06:17:42PM -0500, Mike Gilbert wrote: > Bug: https://bugs.gentoo.org/759433 > Signed-off-by: Mike Gilbert > --- > dev-util/meson/files/meson-array | 18 ++ > ...on-0.55.3.ebuild => meson-0.55.3-r1.ebuild} | 5 + > dev-util/meson/meson-.ebuild | 5 + > 3 files changed, 28 insertions(+) > create mode 100644 dev-util/meson/files/meson-array > rename dev-util/meson/{meson-0.55.3.ebuild => meson-0.55.3-r1.ebuild} (96%) > > diff --git a/dev-util/meson/files/meson-array > b/dev-util/meson/files/meson-array > new file mode 100644 > index ..0f4e8c7c6389 > --- /dev/null > +++ b/dev-util/meson/files/meson-array > @@ -0,0 +1,18 @@ > +#!/usr/bin/env python > + > +import itertools > +import shlex > +import sys > + > +def quote(s): > +return "'" + s.replace("\\", "").replace("'", "\\'") + "'" > + > +def main(): > +args = sys.argv[1:] > +args = (shlex.split(x) for x in args) > +args = itertools.chain.from_iterable(args) > +args = (quote(x) for x in args) > +print("[" + ", ".join(args) + "]") > + > +if __name__ == "__main__": > +main() > diff --git a/dev-util/meson/meson-0.55.3.ebuild > b/dev-util/meson/meson-0.55.3-r1.ebuild > similarity index 96% > rename from dev-util/meson/meson-0.55.3.ebuild > rename to dev-util/meson/meson-0.55.3-r1.ebuild > index ddf27ccdc725..4708a46b324f 100644 > --- a/dev-util/meson/meson-0.55.3.ebuild > +++ b/dev-util/meson/meson-0.55.3-r1.ebuild > @@ -82,6 +82,11 @@ python_test() { > ) || die "Testing failed with ${EPYTHON}" > } > > +python_install() { > + distutils-r1_python_install > + python_doscript "${FILESDIR}/meson-array" > +} > + > python_install_all() { > distutils-r1_python_install_all > > diff --git a/dev-util/meson/meson-.ebuild > b/dev-util/meson/meson-.ebuild > index 38ccf9179e21..1cdd142a3f79 100644 > --- a/dev-util/meson/meson-.ebuild > +++ b/dev-util/meson/meson-.ebuild > @@ -82,6 +82,11 @@ python_test() { > ) || die "Testing failed with ${EPYTHON}" > } > > +python_install() { > + distutils-r1_python_install > + python_doscript "${FILESDIR}/meson-array" > +} > + > python_install_all() { > distutils-r1_python_install_all > > -- > 2.29.2 I am fully aware I don't have full context for this, so fill me in if I am missing something. Reading this patch series and the bug linked in this message, it looks like we are trying to make meson.eclass work if /usr/bin/python is missing. My question is why? as far as I know /usr/bin/python is standard like /bin/sh; when a version of python is installed this link is always available. If /usr/bin/python is going away, it is going to break not only this but every python script that has "#!/usr/bin/python" or "#!/usr/bin/env python" as a shebang line. If /usr/bin/python is going away, what about /usr/bin/python3? If that isn't going away, the easier thing to do is to tweak the eclass to call it instead. 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. Please do not apply this patch to meson; I think we can figure something out that is better. Also, see my comments on the third patch in the series for more context. Thanks, William signature.asc Description: PGP signature
[gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script
Bug: https://bugs.gentoo.org/759433 Signed-off-by: Mike Gilbert --- dev-util/meson/files/meson-array | 18 ++ ...on-0.55.3.ebuild => meson-0.55.3-r1.ebuild} | 5 + dev-util/meson/meson-.ebuild | 5 + 3 files changed, 28 insertions(+) create mode 100644 dev-util/meson/files/meson-array rename dev-util/meson/{meson-0.55.3.ebuild => meson-0.55.3-r1.ebuild} (96%) diff --git a/dev-util/meson/files/meson-array b/dev-util/meson/files/meson-array new file mode 100644 index ..0f4e8c7c6389 --- /dev/null +++ b/dev-util/meson/files/meson-array @@ -0,0 +1,18 @@ +#!/usr/bin/env python + +import itertools +import shlex +import sys + +def quote(s): +return "'" + s.replace("\\", "").replace("'", "\\'") + "'" + +def main(): +args = sys.argv[1:] +args = (shlex.split(x) for x in args) +args = itertools.chain.from_iterable(args) +args = (quote(x) for x in args) +print("[" + ", ".join(args) + "]") + +if __name__ == "__main__": +main() diff --git a/dev-util/meson/meson-0.55.3.ebuild b/dev-util/meson/meson-0.55.3-r1.ebuild similarity index 96% rename from dev-util/meson/meson-0.55.3.ebuild rename to dev-util/meson/meson-0.55.3-r1.ebuild index ddf27ccdc725..4708a46b324f 100644 --- a/dev-util/meson/meson-0.55.3.ebuild +++ b/dev-util/meson/meson-0.55.3-r1.ebuild @@ -82,6 +82,11 @@ python_test() { ) || die "Testing failed with ${EPYTHON}" } +python_install() { + distutils-r1_python_install + python_doscript "${FILESDIR}/meson-array" +} + python_install_all() { distutils-r1_python_install_all diff --git a/dev-util/meson/meson-.ebuild b/dev-util/meson/meson-.ebuild index 38ccf9179e21..1cdd142a3f79 100644 --- a/dev-util/meson/meson-.ebuild +++ b/dev-util/meson/meson-.ebuild @@ -82,6 +82,11 @@ python_test() { ) || die "Testing failed with ${EPYTHON}" } +python_install() { + distutils-r1_python_install + python_doscript "${FILESDIR}/meson-array" +} + python_install_all() { distutils-r1_python_install_all -- 2.29.2