FS#59844 - [namcap] /usr/bin/namcap should use /usr/bin/python(3), not /usr/bin/env python3

Attached to Project: Arch Linux
Opened by Antony Lee (anntzer) - Tuesday, 28 August 2018, 12:24 GMT
Last edited by Jelle van der Waa (jelly) - Friday, 11 August 2023, 15:51 GMT
Task Type Bug Report
Category Arch Projects
Status Closed
Assigned To Kyle Keen (keenerd)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
Currently, the /usr/bin/namcap wrapper script invokes python through /usr/bin/env. Due to this, namcap doesn't work when in a virtualenv.
There is no reason to use /usr/bin/env in the wrapper script: you know exactly where the package is going to be installed, it's in /usr; therefore, python should just be invoked as /usr/bin/python (or /usr/bin/python3).

Additional info:
* package version(s): namcap 3.2.8-2
* config and/or log files etc.: N/A

Steps to reproduce:
$ python -mvenv /tmp/foobar && source activate /tmp/foobar/bin/activate
$ namcap ---> error

Edit /usr/bin/namcap to use /usr/bin/python3.
$ namcap ---> success
This task depends upon

Closed by  Jelle van der Waa (jelly)
Friday, 11 August 2023, 15:51 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/pacman/namc ap/issues/52
Comment by Eli Schwartz (eschwartz) - Tuesday, 28 August 2018, 13:43 GMT
  • Field changed: Summary ([namcap] /usr/bin/namcap should use /usr/bin/python(3), not /usr/bin/env python3 → {namcap} /usr/bin/namcap should use /usr/bin/python(3), not /usr/bin/env python3)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Category (Packages: Extra → Arch Projects)
  • Task assigned to Kyle Keen (keenerd)
I do agree with you, however, apparently the python ecosystem at large is constantly providing the terribad advice to use the shebang line:
#!/usr/bin/env python3

Since apparently, scripts breaking in virtualenvs is considered a good thing, rather than encoding the location of sys.executable (which modern pip finally does). Although I'm not sure how that translated to using /usr/bin/env in a bash script that already does PATH lookup.

I'm inclined to think we shouldn't go to special efforts to hardcode the python binary, what if people actually want to install namcap inside a virtualenv?

The correct solution IMHO is to get rid of the wrapper entirely, move its decompression logic into namcap proper, and use setuptools entry points.
Comment by Antony Lee (anntzer) - Tuesday, 28 August 2018, 14:25 GMT
> The correct solution IMHO is to get rid of the wrapper entirely, move its decompression logic into namcap proper, and use setuptools entry points.

Agreed.

> I'm inclined to think we shouldn't go to special efforts to hardcode the python binary, what if people actually want to install namcap inside a virtualenv?

I would argue that the PKGBUILD should do the replacement, then (if the above cannot be done): in spirit this is not different from a PKGBUILD for a third party project that would replace, say, /usr/bin/python by /usr/bin/python2.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Loading...