search

indygreg / python-build-standalone

Produce redistributable builds of Python
BSD 3-Clause "New" or "Revised" License
1.71k stars 107 forks source link

Add `python` executable on Unix systems #212

Closed ofek closed 4 months ago

ofek commented 4 months ago

Originally discovered in https://github.com/pypa/hatch/discussions/1253

Could you please add something like python3 where it's just a link to the actual executable?

indygreg commented 4 months ago

Is a python executable expected now? I'm old enough to remember when people were saying to always run python2 or python3 and that python was going to go away.

What's the latest guidance on when to have a python executable/symlink? Is there a PEP I'm out-of-compliance with for not providing a python?

ofek commented 4 months ago

Versioned Python executables in my experience is an artifact of how Linux systems are set up due to the dependence on Python. In other contexts, like the Windows artifacts produced here, it is just python and you manage PATH or a shim does it for you.

mikeshardmind commented 4 months ago

I wouldn't expect a python executable/symlink to exist. I doubt anyone is blind unpacking this to /usr/local/bin (or similar) in a way that would cause problems or the fact that python3 is provided (Rather than python3.x) could also have caused problems. I would expect anyone needing such a symlink to just create it when needed.

What's the latest guidance on when to have a python executable/symlink?

Debian, Ubuntu, and RHEL don't provide a python symlink by default, with RHEL having a blogpost a few years ago that went over the reason why. I don't think I've seen any python provided guidance here, but the general trend for years has been that people should be specific about the python interpreter they are depending on in both scripts and applications which is a reasonable stance. This was a decision to break things that didn't specify rather than guess they were correctly okay with any python version.

On openSUSE, python is still python 2.7 and applications and scripts expecting python3 or a specific version need to specify it still. This is also a reasonable stance that leaned toward deciding not to break all older things and newer things needed to continue specifying python3

indygreg commented 4 months ago

I don't really see a problem with adding a python symlink: it should be pretty harmless.

I'm just wondering why now. This project is years old and seemingly nobody complained about the lack of a python by now and python3 (symlink) and pythonX.Y (e.g. python3.12) actual executable were fine.

FWIW CPython's build system doesn't produce a python (but does a python3 symlink), which is probably why I never thought about adding a python. That biases me towards thinking that any workflow expecting a python to exist is subtly out-of-compliance with the expectations of the CPython developers. I'd like to think that if CPython wanted a python, they'd be installing it by default. Then opinionated distros could rip it out as part of their... opinionated stance on how to package Python. But that's on the distros.

I'm still unsure what we should do here :/

ofek commented 4 months ago

I would personally err on the side of consistent UX and allow folks to unpack to a given location with the knowledge that there will be a standard name for the interpreter binary (minus the .exe on non-Windows systems).

merwok commented 4 months ago

The official position / recommendation is recorded here: https://peps.python.org/pep-0394/ It is possible to have a python command to call python3.y, but is left to OS maintainers. In addition, in virtual environnements we do have a python command.

indygreg commented 4 months ago

PEP 394 seems to give PBS the permission to ship a python. I don't see an obvious downside to doing it. So let's do it.