Re: [gentoo-dev] [PATCH 1/3] dev-util/meson: install meson-array script

2020-12-17 Thread Michał Górny
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

2020-12-17 Thread James Le Cuirot
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

2020-12-17 Thread Mike Gilbert
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

2020-12-17 Thread Mike Gilbert
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

2020-12-17 Thread William Hubbs
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

2020-12-12 Thread Mike Gilbert
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

2020-12-12 Thread William Hubbs
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

2020-12-12 Thread Mike Gilbert
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

2020-12-12 Thread William Hubbs
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

2020-12-11 Thread Mike Gilbert
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