| martinvonz | |
| mharbison72 | |
| durin42 |
| hg-reviewers |
This change is long overdue IMO.
.. bc::
Makefile now uses `python3` instead of `python` by default on non-Windows platforms. This means Mercurial will be built and run with Python 3 instead of Python 2.7 by default. To continue using Python 2, set the PYTHON variable. e.g. `make install PYTHON=python2.7`.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
This will break Windows by default, because py3 is still named python.exe. Alternately, I've been using using PYTHON="py -3" to invoke make.
The command issued to the buildbot will need to explicitly use PYTHON="py -2" to keep that happy. Probably also need to invoke run-tests.py with the right python too, so that $PYTHON is correct. It looks like the shebang lines are already $PYTHON, through some aren't quoted.
CC @durin42
I'm not sure what we should do here. We probably can't change the default only for Windows somehow? (My make-fu is not awesome)
The command issued to the buildbot will need to explicitly use PYTHON="py -2" to keep that happy. Probably also need to invoke run-tests.py with the right python too, so that $PYTHON is correct. It looks like the shebang lines are already $PYTHON, through some aren't quoted.
Okay, I'll see about wiring that up tonight or tomorrow then. I believe that's the only (other) thing blocking this?
CC @durin42
ifeq ($(shell uname -o), Msys) PYTHON?=py -2 else PYTHON?=python3 endif
Generally I just test uname, but that prints "MINGW32_NT-6.2" on Windows 10 and "MINGW32_NT-6.1" on Win7.
The command issued to the buildbot will need to explicitly use PYTHON="py -2" to keep that happy. Probably also need to invoke run-tests.py with the right python too, so that $PYTHON is correct. It looks like the shebang lines are already $PYTHON, through some aren't quoted.
Okay, I'll see about wiring that up tonight or tomorrow then. I believe that's the only (other) thing blocking this?
I think that's correct. I vaguely recall that some test helpers were run like ./foo.py at one point, which works on Windows because the registered file handler for *.py is python2. But that's more of an issue with py3 porting, and shouldn't block this. And maybe it was fixed with all of the $PYTHON work you did.
ifeq ($(shell uname -o), Msys) PYTHON?=py -2 else PYTHON?=python3 endif
Perhaps, ifeq($(OS),Windows_NT) would work. My .profile had one.
I've seen ifeq($(OS),Windows_NT) used a lot. Although OS may be something else under msys. I'm away from my Windows machine until Sunday. I'll send a revision once I've had time to test on Windows.
I can confirm that this is the correct environment variable under msys on Windows 7 and 10, and it works in the makefile as suggested.
To continue using Python 2, set the PYTHON variable. e.g.
make install PYTHON=python2.7 or
make install PYTHON=py.exe -2.
The "py -2" part needs to be quoted.
I'm not super excited to deal with this on Windows just yet, but I can't dispute the rationale. There are two traps for anybody dealing with this on Windows to be aware of:
I know @durin42 took a whack at #1; I'm not sure if there's something we can do about #2. (I realize I could just edit $PATH, but it seems that the point of py.exe is to keep python.exe off of $PATH so that multiple installs can be managed. IIRC, it's not added to $PATH by default on installation.) Maybe we can just copy the dll to the local directory as part of setup.py?
I seriously question whether we need a Makefile at all [on Windows]: our Makefile is just a glorified shell script and isn't doing much in terms of dependency management. I'm tempted to move the packaging targets to contrib/packaging and replace the remaining build targets with a build.py script.
That seems OK to me. I like being able to mindlessly run the same commands on any platform. But in practice I only ever run make clean and make local everywhere, and make install-bin on unix systems. Maybe a python script could handle that everywhere. And I'd be fine with the packaging targets elsewhere in any case.
Thanks!