"sudo python3 -m pip
install -e ."

You’ve already started down a problematic road. I recommend installing root level Python packages through your system package manager. (apt for debian, or whatever RedHat is using now).

If a package you need isn’t available from the system level virtual environments are your friend.

I’ve never used pkexec. Generally, just use sudo. There’s an -E flag to preserve the environment. We generally write bash wrappers that set whatever environment we need.


From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of c.buhtz@posteo.jp <c.buhtz@posteo.jp>
Date: Sunday, December 18, 2022 at 12:56 PM
To: Python-list@python.org <Python-list@python.org>
Subject: pip/setuptools: Entry points not visible from pkexec-root-environment *** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

Hello,

when I install a package on a GNU/Linux system via "sudo python3 -m pip
install -e ."

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Gerard,
thank you for your reply.

Am 18.12.2022 19:45 schrieb Weatherby,Gerard:

"sudo python3 -m pip
install -e ."

You’ve already started down a problematic road. I recommend installing
root level Python packages through your system package manager. (apt
for debian, or whatever RedHat is using now).

I'm totally with you at this point.

It is clear for me that distro maintainers sometimes using different mechanics.
But I'm the upstream maintainer and before handing offer a release to
the distro that thing need to run without a distro. And that is pip. I
also know a quit old project using "make" for that.

This question is independent from distros.

I’ve never used pkexec. Generally, just use sudo.

They are two very different things. There is a strict reason why I need
to use pkexec here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 19 Dec 2022 at 04:56, <c.buhtz@posteo.jp> wrote:

Hello,

when I install a package on a GNU/Linux system via "sudo python3 -m pip install -e ." that defines entry points in its pyproject.toml the entry
point starter scripts are located in /usr/locale/bin.

That folder is in PATH for "regular" root users and by "sudo su" roots
users.

But I need to start that entry points via "pkexec".
But in the environment started by "pkexec" the PATH does not contain /usr/local/bin.

So what can I do?

I don't need a hack or workaround but an "elegant" solution.

Does it have to be in path? Can't you say
/usr/local/bin/entrypointname? Not sure what constitutes an elegant
solution here.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Pip is fine for most packages, as it looks like you know. Some distros
put some packages in unusual places, and those are the ones that either
are not or should not be installed via pip. Which ones varies from
distro to distro. (I just include this information here for others who
haven't discovered it yet).

You asked for something that's not a hack, but here's a hack anyway :).
Worth reading for the caveats -

https://stackoverflow.com/questions/50783033/execute-pkexec-command-on-a-different-path

I think the most natural way is to launch it with a script that adds
your desired path to the pkexec environment. What I don't know is if
that script needs elevated permissions itself, but you probably already
know about that.

On 12/18/2022 2:23 PM, c.buhtz@posteo.jp wrote:

Dear Gerard,
thank you for your reply.

Am 18.12.2022 19:45 schrieb Weatherby,Gerard:

"sudo python3 -m pip
install -e ."

You’ve already started down a problematic road. I recommend installing
root level Python packages through your system package manager. (apt
for debian, or whatever RedHat is using now).

I'm totally with you at this point.

It is clear for me that distro maintainers sometimes using different mechanics.
But I'm the upstream maintainer and before handing offer a release to
the distro that thing need to run without a distro. And that is pip. I
also know a quit old project using "make" for that.

This question is independent from distros.

I’ve never used pkexec. Generally, just use sudo.

They are two very different things. There is a strict reason why I need
to use pkexec here.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Chris,

thank you for your reply.

Am 18.12.2022 20:27 schrieb Chris Angelico:

Does it have to be in path? Can't you say
/usr/local/bin/entrypointname? Not sure what constitutes an elegant
solution here.

I asked that myself. My current solution do determine the full path of
the entrypoint via "which entrypoint".
I also think this is to my current knowledge the best solution.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18 Dec 2022, at 17:57, c.buhtz@posteo.jp wrote:

Hello,

when I install a package on a GNU/Linux system via "sudo python3 -m pip install -e ." that defines entry points in its pyproject.toml the entry
point starter scripts are located in /usr/locale/bin.

That folder is in PATH for "regular" root users and by "sudo su" roots
users.

But I need to start that entry points via "pkexec".
But in the environment started by "pkexec" the PATH does not contain /usr/local/bin.

So what can I do?

Why are asking on this list and discuss.python.org?
Lots of people on this list are also on discuss.python.org.

Barry

I don't need a hack or workaround but an "elegant" solution.
--
https://mail.python.org/mailman/listinfo/python-list

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/18/22 14:07, c.buhtz@posteo.jp wrote:

Dear Chris,

thank you for your reply.

Am 18.12.2022 20:27 schrieb Chris Angelico:

Does it have to be in path? Can't you say
/usr/local/bin/entrypointname? Not sure what constitutes an elegant
solution here.

I asked that myself. My current solution do determine the full path of
the entrypoint via "which entrypoint".
I also think this is to my current knowledge the best solution.

the which command uses your PATH, so I'm not sure you're buying anything
new there....

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 18.12.2022 22:37 schrieb Mats Wichmann:

the which command uses your PATH, so I'm not sure you're buying
anything new there....

I'm using which before entering pkexec. ;)

I'll show a demonstrator project later.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Barry,
thanks for reply and asking back.

Am 18.12.2022 22:33 schrieb Barry:

Why are asking on this list and discuss.python.org?

To be exact I'm asking in the "Packaging" section of
"discuss.python.org". To my knowledge that section is the official
channel of "pypa/pip" project pointed to from there own README.md [1].
To be complete. I also asked in in context of "pypa/setuptools" [2] and
on the debian-python mailing list.

Not all questions are exactly the same but touching the same meta topic. "pypa/setuptools" themselfs pointed me to the fact that they are not responsible for generating the entry-point-scripts but "pypa/pip" is. No
matter both have "pypa/" in their names they seem technically different.
This has reasons but is very confusing for "developers from the outside"
like me. There are also alternative build-tools other then "setuptools".
That is why I asked on that python-list here, too. The later was in the
hope to maybe be pointed to alternative solutions away from setuptools
and/or pip.

My apologize. When I decide for a solution I will point you to a
demonstrator repository illustrating that solution.

[1] -- <https://github.com/pypa/pip#readme>
[2] -- <https://github.com/pypa/setuptools/discussions/3729>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 19 Dec 2022 at 17:30, <c.buhtz@posteo.jp> wrote:

Am 18.12.2022 22:37 schrieb Mats Wichmann:

the which command uses your PATH, so I'm not sure you're buying
anything new there....

I'm using which before entering pkexec. ;)

I'll show a demonstrator project later.

Hmm, then I'm not sure what you're *losing* here. The problem, as I
understand it, is that the scripts are getting installed into
/usr/local/bin (which is on PATH at the time they're installed), but
pkexec has a restricted PATH. So if you use which before pkexec'ing,
wouldn't you find the scripts, and then be able to run them without
regard to PATH?

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dear Chris,
thanks for asking back and my apologize for being to broad in my way of
asking (in a foreign language).

Am 19.12.2022 07:40 schrieb Chris Angelico:

Hmm, then I'm not sure what you're *losing* here. The problem, as I understand it, is that the scripts are getting installed into
/usr/local/bin (which is on PATH at the time they're installed), but
pkexec has a restricted PATH. So if you use which before pkexec'ing,
wouldn't you find the scripts, and then be able to run them without
regard to PATH?

Absolut correct. This works.

The question is if this is a "good" or "elegant" way from the viewpoint
of different communities/projects (e.g. Python, setuptools, pip, other build-systems, distros, something I forgot).

I assume that I'm not the first person with such a use case. So there
could be solutions out there. Maybe they are standardized solutions out
there; e.g. a magic feature of setuptools or pip I haven't noticed yet.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 19 Dec 2022 at 19:38, <c.buhtz@posteo.jp> wrote:

Dear Chris,
thanks for asking back and my apologize for being to broad in my way of asking (in a foreign language).

Am 19.12.2022 07:40 schrieb Chris Angelico:

Hmm, then I'm not sure what you're *losing* here. The problem, as I understand it, is that the scripts are getting installed into /usr/local/bin (which is on PATH at the time they're installed), but
pkexec has a restricted PATH. So if you use which before pkexec'ing, wouldn't you find the scripts, and then be able to run them without
regard to PATH?

Absolut correct. This works.

The question is if this is a "good" or "elegant" way from the viewpoint
of different communities/projects (e.g. Python, setuptools, pip, other build-systems, distros, something I forgot).

Ah! Then, my response is: Yes, it is definitely a good/elegant
solution. I've often created scripts that install into somewhere (eg
systemd, cron, ifupdown) by using 'which' to figure something out, and
then posting the full path into the corresponding file. It's a
convenient way to ensure that the exact same program would be used.

Notably, "which python3" will ensure that you run on the
currently-active Python interpreter; this includes virtual
environments. Very convenient.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)