Python executable name in Makefiles #253
Description
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.
Activity
stefanv commentedon Aug 23, 2023
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
pythonmissing butpython3found is totally fine.stefanv commentedon Aug 23, 2023
Hah, I see they have a package for that:
python-is-python3.bsipocz commentedon Aug 24, 2023
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 commentedon Oct 3, 2023
According tohttps://peps.python.org/pep-0394/#migration-notes:
My understanding is that
python3should always work and sometimespythonwon't.agriyakhetarpal commentedon Mar 13, 2024
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
noxenvironments/sessions1. Here is a referencenoxfile.pywith 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 setvenv_backendtoNone.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 hugoto 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
noxwas chosen because it was preferable to using DSLs liketox– we could very well have Scientific Python INcantations (spin) or SciPy'sdev.pyadapted for this use case, or even something likepydoitorinvoke– the latter tools are more general in purpose. ↩