Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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 Eli Schwartz (eschwartz) - Tuesday, 28 August 2018, 13:43 GMT
Task Type Bug Report
Category Arch Projects
Status Assigned
Assigned To Kyle Keen (keenerd)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
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

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.

Loading...