Bug #1143

Use explicit python version in Debian startup script

Added by Rob Baer almost 2 years ago. Updated almost 2 years ago.

Status:NewStart date:03/04/2017
Priority:NormalDue date:
Assignee:Joel Palmius% Done:

0%

Category:Programming
Target version:MakeHuman 1.1.2

Description

Makehuman 1.1.1 ubuntu 16.04

First, my premise here is that the ppa installs to /usr/bin/ and that the program is to be startedby typing makehuman at the command prompt (I know, sad I'm not clear about this)

In starting the new release, I got:

rwbaer@Aspire:/usr/bin$ makehuman
File "makehuman.py", line 452
print "\n" + getCopyrightMessage() + "\n"
^
SyntaxError: invalid syntax
rwbaer@Aspire:/usr/bin$ python
Python 3.6.0 |Anaconda 4.3.0 (64-bit)| (default, Dec 23 2016, 12:22:00)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.

[1]+ Stopped python
rwbaer@Aspire:/usr/bin$ ^C
rwbaer@Aspire:/usr/bin$

The issue here is a direct side-effect of the fact that I have been exploring Anaconda Python 3 for the MH port to python 3, and consequently Anaconda python 3.6 was installed my default python. It eminds us not to assume a user's environment. A python version check could be used to provide a new user with a more useful message about what went wrong.

This same check will help (and be important) going the other way once the python 3 port is complete.

I don't think this is necessary on Windows where Python supposedly "comes with" but it also might help on OSX depending how that build is put together.

History

#1 Updated by Aranuvir # almost 2 years ago

Can you post the results from typing 'python2 --version' and 'python --version'? It seems Ubuntu can't find Python2, this looks more like an inconsistent system, though the package manger should resolve the dependencies? (BTW, you don't need to cd /usr/bin, it's usually in your $PATH environment)

#2 Updated by Jonas Hauquier almost 2 years ago

The problem here is that print() is a functiin, not a statement in py3
The proper way of fixing this, and have py2/3 compatibility is using

From __future__ import print_function, and use functions for all prints.

#3 Updated by Jonas Hauquier almost 2 years ago

Also the startup script for the current stable should probably explicitate the py version in the shebang

#!/usr/bin/python2

#4 Updated by Rob Baer almost 2 years ago

But the point is, we can't afford to make assumptions that might not be true for all users.

For the record here's how the python versions resolve for me,

rwbaer@Aspire:~$ python2 --version
Python 2.7.12
rwbaer@Aspire:~$ python3 --version
Python 3.6.0 :: Anaconda 4.3.0 (64-bit)
rwbaer@Aspire:~$ python --version
Python 3.6.0 :: Anaconda 4.3.0 (64-bit)
rwbaer@Aspire:~$
rwbaer@Aspire:~$ python3.5 --version
Python 3.5.2
rwbaer@Aspire:~$

And yes, we should fix the print() statement too...

But that still won't make the code run under python 3. The code will just fail elsewhere.

#5 Updated by Aranuvir # almost 2 years ago

Just some opinion about the environment:

a) if running MH from source on any OS, it is up to the user to setup an appropriate environment.
b) by using the Windows package the problem of the environment, as you mentioned, is resolved by bundling Python in the package.
c) on Linux a great number of package management tools automatically resolve missing dependencies.

If software is running on a Linux system, making such grave interventions to an environment, that those interventions lead to the equivalent of an inconsistent system, like Anaconda obviously does, this is either a seriously critical bug of Anaconda, or, more likely, the usage beyond its primary scope.

Another question is, can we make MakeHuman forward compatible? In respect of the print statement and targeting for Python3 this should be possible, but can we anticipate, if tomorrow Python4 suddenly wants curly brackets for functions, or any other fancy new stuff?

Doing some quick tests on my system, Python seems to totally ignore the "magic number" in the first line, and does not even crate an error message. IMHO, at least a missing feature, if not a bug. The shebang is just a hint for (unix-like) OSes when the interpreter is not specified.
Based on this observation, I want to emphasize Jonas comment to force python2(.7?) on all the scripts, the basic makehuman bash script, as well as the scripts in buildscripts/ppa/extras/ and buildscripts/deb/bin, etc. Perhaps the build-scripts should call the basic makehuman shell script instead, So there are less places where to specify the interpreter.

#6 Updated by Rob Baer almost 2 years ago

Aranuvir (Moderator) wrote:

Just some opinion about the environment:

a) if running MH from source on any OS, it is up to the user to setup an appropriate environment.

Well I just learned that I think like a Windows user (and maybe a Mac user) and not like a Linux user. ;-) When I download software from Bitbucket or Mercurial I'm fine with the idea that I'm running from source, and it's my job to prepare the environment accordingly. When I download a ppa, MY WINDOWS MENTALITY leaves the "running from source mindset" behind; I expect required dependencies to be rolled up ready to run; if it's C++ code, I don't expect to compile before running unless this is scripted in.

c) on Linux a great number of package management tools automatically resolve missing dependencies.

If software is running on a Linux system, making such grave interventions to an environment, that those interventions lead to the equivalent of an inconsistent system, like Anaconda obviously does, this is either a seriously critical bug of Anaconda, or, more likely, the usage beyond its primary scope.

"Grave interventions to the environment"?. "equivalent of an inconsistent system, like Anaconda"? --Inflammatory but wrong concepts ;=)

Makehuman provides a package with a startup script. On Linux distros it seems perfectly fair to think python will be installed. For now, it also seems fair to assume both python 2 and python 3 will be available. However, it seems unfair to assume that the python command points at python2. The death of python2 is announced. My guess is that it won't be too long before the python command points at python3 on many distros.

Anaconda per se has nothing to do with this (except that I shared too much information about how I came to recognize the issue). The evolution of distros will eventually lead to the same problem destination.

Rather than a "test of default version" as a I suggested, Jonas is just saying to change the line in our startup script from:

python makehuman.py "$@"  to
python2 makehuman.py "$@" 


This is obviously the right way to accomplish the end goal and supports a path forward.

I don't see us developing a version of MakeHuman that is python-version agnostic . The transition from python2 to python3 will mean upgrading the script accordingly. This separates us from the timing of various distros going to python3 as their default.

Another question is, can we make MakeHuman forward compatible? In respect of the print statement and targeting for Python3 this should be possible, but can we anticipate, if tomorrow Python4 suddenly wants curly brackets for functions, or any other fancy new stuff?

I think Jonas' point is that there are easy ways to prepare a python2 codebase for python3 compatibility. It seems only sensible to avoid future work for ourselves if and when we can. Never heard of python4 :))

EDIT Now thanks to you I have. https://opensource.com/life/14/9/why-python-4-wont-be-python-3
Doesn't look like we should expect curly braces. "...we would likely see Python 4.0 some time in 2023..."

Doing some quick tests on my system, Python seems to totally ignore the "magic number" in the first line, and does not even crate an error message. IMHO, at least a missing feature, if not a bug. The shebang is just a hint for (unix-like) OSes when the interpreter is not specified.

Yeah, I haven't figured out how to make shebang do anything useful either. Perhaps I use the wrong shell. Environments are not uniform across all users. ;-)

#7 Updated by Rob Baer almost 2 years ago

  • Subject changed from Add python version check to early in start-up code to Use explicit python version in Debian startup script

Fixing title to match proper solution

#8 Updated by Aranuvir # almost 2 years ago

Generally the shebang makes sense, e.g. in the way that you can start a program from console by typing:

rwbaer@Aspire:~$./test.py

instead of
rwbaer@Aspire:~$python2 test.py

But I had wished that the python interpreter takes care of it, too, and at least gives a warning if e.g. python3 should execute a script that was intended by it's shebang definition (#!/usr/bin/env python2.7) to run on python2.7.

#9 Updated by Jonas Hauquier almost 2 years ago

Exactly.
To summarize:

  • In a startup shell script, explicitly use the "python2" interpreter.
  • Modify the shebang in the makehuman.py main file to /usr/bin/python2 explicitly (or the more general #!/usr/bin/env python2, but for some reason debian discourages this use)

This as long as a stable python3 port has not happened.
In the long run, the python2 can be changed to "python" again, and mh should work with both python2 and python3

Also available in: Atom