Re: bin/pip3.12 or bin/pip-3.12

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Hi Adam,

thanks for giving a rationale.

Am Wed, 7 May 2025 06:30:11 +0200
schrieb Adam <adam%netbsd.org@localhost>:

> I would like to keep all Python binaries separated with the version suffix with a dash.

I agree in principle, and the Python folks seem to agree, too, for
things they add. But there's legacy.

> Also, some files end with a digit, like 'pyrcc5' or 'autopep8'.
> If the dash was omitted, it would be 'pyrcc53.13' and 'autopep83.13'
> which is obviously very confusing.

Do you have other examples? I find pyrcc5 and autopep8 in Debian only
packaged in one version, not depending on underlying python. Those are
end-user programs that don't really come as python libraries that you'd
need multiversioned. I see that with pkgsrc's support for building
packages with differing pythons next to each other, you face the
problem of adding versioning to them. It is sensible to append versions
with a dash, then.

I also see that I need to add ALTERNATIVES handling to my builds for
these cases where I really do need a suffix-less command for the users,
and where it doesn't really matter which version it is (so the default
python, and preferrably not even built with the others).

> I think this should be a standard across all the packages. […[
> So, as for me, I would keep pip-${PYVERSUFFIX} with the dash.

A standard with exceptions. The legacy is

python$PYVERSUFFIX
python$PYVERSUFFIX-config
pip$PYVERSUFFIX
pydoc$PYVERSUFFIX

Python folks woke up to the issues and other packages have the dash:

virtualenv-$PYVERSUFFIX
wheel-$PYVERSUFFIX
[…]

Looking at my pkgsrc prefix for the obvious python stuff, I see

No dash:

pip3.10
pip3.11
pip3.12
pydoc2.7
pydoc3.10
pydoc3.11
pydoc3.12
python2.7
python2.7-config
python3.10
python3.10-config
python3.11
python3.11-config
python3.12
python3.12-config

With dash:

py.test-3.10
py.test-3.11
py.test-3.12
pybabel-3.12
pybind11-config-3.10
pybind11-config-3.11
pybind11-config-3.12
pyftmerge-3.10
pyftmerge-3.11
pyftmerge-3.12
pyftsubset-3.10
pyftsubset-3.11
pyftsubset-3.12
pygmentize-3.12
pyproject-build-3.10
pyproject-build-3.11
pyproject-build-3.12
pyrsa-decrypt-3.12
pyrsa-encrypt-3.12
pyrsa-keygen-3.12
pyrsa-priv2pub-3.12
pyrsa-sign-3.12
pyrsa-verify-3.12
pytest-3.10
pytest-3.11
pytest-3.12
pythran-3.10
pythran-3.11
pythran-3.12
pythran-config-3.10
pythran-config-3.11
pythran-config-3.12
virtualenv-3.10
virtualenv-3.11
virtualenv-3.12
wheel-3.10
wheel-3.11
wheel-3.12

(PS: Debian doesn't version wheel at all, just /usr/bin/wheel, so I
guess it is also of the category „python version it runs with does not
matter”. Maybe it turns into a wheel ALTERNATIVE for my installs, too.)

So from my perspective, the right thing to do is to default to the
dash, _except_ for

python
python-config
pydoc
pip

Those have the lecacy and expectation of dash-less version suffix (or
even infix). You break a lot of assumption by changing these. Please
don't break established assumptions;-) Any new package will follow the
more robust versioning, I presume. Maybe there's even a PEP thingie
that explains the version suffix exceptions?

Those exceptions should be noted as comments in the respective
Makefiles, or maybe with a variable once a central mechanism for the
version numbering is in place.

Can we agree on that?


Alrighty then,

Thomas

PS: I dream of a world where you wouldn't have to cater to the need to
have N versions of an evolving partially self-conflicting programming
language installed at the same time. Shame on you, Python, again and
again!

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg