RPCs do not work with Python 3.5

[lucach]

Currently the master branch targets python 3.6 and, indeed, the documentation explicitely mentions apt install python3.6.

However, that command does not set python3.6 as the default binary for providing python3 when there's already a version of python 3 installed on the system (e.g., python3.5).

During a recent contest (setup: master branch on ubuntu 16.04), this led to running CMS with python3.5, believing instead that it was running with the explicitely installed python3.6. The overall system works just fine, but some slightly variations in the internals of JSON strings make RPCs silently fail.

Even if Ubuntu 18.04 LTS ships with python3.6, I'd think that this is something which should be accounted for somewhere (at least, under the troubleshooting section of the documentation).

[stefano-maggiolo]

Do you have a stacktrace? If it's a quick fix we might implement it. Regardless, as you say, we should highlight that we require >=3.6 and that it needs to be enabled if 3.5 is already in the system.

Related: the best workaround is probably running on a virtualenv.

[lucach]

Do you have a stacktrace?

Unfortunately not (oddly enough, LogService was not showing any related error, not even a single one! - that drove me crazy). I understood that it was a JSON-related issue when I tried to start RWS, which couldn't successfully decode messages from ProxyService.

Related: the best workaround is probably running on a virtualenv.

Sure, but it is not uncommon to setup machines from scratch just for a contest. In this cases, one would probably not even bother with virtualenv and similar proper solutions.

[lw]

A couple of questions:

• You said you were running the master branch on Ubuntu 16.04 in non-venv mode. The master branch requires newer versions for most dependencies than those that are provided in the Ubuntu 16.04 repo: are you sure the issue wasn't just a version mismatch?
• Once you run setup.py install using a given Python interpreter, the shebang of all files that are installed is changed to match the path of that interpreter. Were you running CMS in non-installed mode? Or did you run setup.py install with Python 3.5?

[lucach]

Dependencies were installed globally with pip3. CMS was installed, python3 setup.py install was issued believing it was running with python3.6 but, instead, got installed with python3.5.

The problem got solved by setting python3.6 as the default alternative for providing python3, reinstalling with setup.py install and relaunching affected services.

[lw]

Thanks for the clarification!

You could also have solved the issue by just launching python3.6 setup.py install, without switching the Python default version from 3.5 to 3.6. The installer would have taken care of setting up CMS to use the right interpreter in the future regardless of the default.

[lucach]

You could also have solved the issue by just launching python3.6 setup.py install, without switching the Python default version from 3.5 to 3.6.

Correct. I did that way just to play it safe, given the strange behaviour I was observing.