Python executable name in Makefiles

[alphapapa]

@jarrodmillman @stefanv

While working on numpy/numpy.org#668 today, I had to edit the numpy.org Makefile to call python3 rather than python. On Debian 11, there is no python by default, only python3.

Since Python 2 is officially EOL, I guess it would be appropriate to switch to calling python3 in this project's Makefile, as well as the ones for numpy.org and scientific-python.org, but I'd like to ask for feedback from users before making a PR that does so. Since users of these projects are on a variety of platforms, including e.g. Windows and Anaconda, I wouldn't want to make a change that would just break it for a different set of users. If necessary, we could define an alias at the beginning of the Makefile that automatically detects which name to use.

What do you think? Thanks.

[stefanv]

Yes, I suspect Debian's behavior is not what you'd expect. Python should be available, and is in any created virtual environment. But, a detection line that handles python missing but python3 found is totally fine.

[stefanv]

Hah, I see they have a package for that: python-is-python3.

[bsipocz]

Imo, Debian's behaviour is in fact the opposite than what one would expect. In this day and age there is only one python, so why call it python3, what does that distinguish it from?

[jarrodmillman]

According tohttps://peps.python.org/pep-0394/#migration-notes:

Even as the Python 2 interpreter becomes less common, it remains reasonable for scripts
to continue to use the python3 convention, rather than just python.

My understanding is that python3 should always work and sometimes python won't.

[agriyakhetarpal]

Hi, we at https://github.com/pybamm-team/pybamm.org (PyBaMM website) have been using this theme since June 2023 and would like to offer some feedback – we removed the Makefile from this theme in favour of using nox environments/sessions¹. Here is a reference noxfile.py with a few sessions if anyone is interested.

The advantages are that it resolves the issues mentioned here, it is a bit more Pythonic and easy to maintain – the only drawback I can think of is that it creates virtual environments at .nox/ which consume a bit of space on disk – but we generally don't have an issue with those if we set venv_backend to None.

Early this year, I have been experimenting with pip-installable binaries for Hugo for this purpose, which are available at https://github.com/agriyakhetarpal/hugo-python-distributions/, I have been keeping them in sync with Hugo releases upstream and I plan to keep them maintained (one can use pipx install hugo to get them). I hope this helps others who are subscribed to this issue and that it can advocate for tooling for static websites that is more in-line with Python standards.

Footnotes

1. nox was chosen because it was preferable to using DSLs like tox – we could very well have Scientific Python INcantations (spin) or SciPy's dev.py adapted for this use case, or even something like pydoit or invoke – the latter tools are more general in purpose. ↩