Package python 3.5 with cura
Closed, ResolvedPublic

Description

After the changes to Cura 2.4

The build is giving the error on Debian Jessie:

CMake Error at /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message): Could NOT find PythonInterp: Found unsuitable version "3.4.2", but required is at least "3.5.0" (found /usr/bin/python3.4) Call Stack (most recent call first): /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:341 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.0/Modules/FindPythonInterp.cmake:153 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:13 (find_package)

This is happening because there is no Python 3.5 for standard Jessie distro.
I thought that the plan was to stick with Python 3.4 for Debian build.

alexei created this task.Feb 9 2017, 5:05 PM
cj added a comment.Feb 9 2017, 6:54 PM

The plan is Python 3.4 for Debian. A commit from upstream was merged into Uranium. The code in that commit requires Python 3.5.

cj added a comment.Feb 9 2017, 7:41 PM

The Cura2 repo also has merged upstream commits that require Python 3.5.

alexei added a comment.EditedFeb 10 2017, 6:40 AM

CJ,
I guess it's some of these: https://code.alephobjects.com/rU7f1172a2146b8ddd6368f35726b3ea262bb27327
We would like to push requirement down for Uranium to Python 3.4 where applicable.
Could you figure out what changes a required to drop to 3.4? If they are minor and we can implement them relatively fast we should do it.

CJ,
With drop to python 3.4 in CMake.txt of Cura2 and Uranium Cura2 builds fine. It crashes CuraEngine though, but it might be better to downgrade these setting now (at least one will be able to build it) and figure the downgrade procedure ASAP.

cj added a comment.Feb 13 2017, 12:45 PM

@all: I was wrong about packaging the python interpreter for Linux; that will take more work than it is worth in this case.

Instead of simply downgrading the merged code, I can modify the CMake files in such a way that they will default to requiring Python 3.5 but can be switched to any Python version with a single configuration argument like:

cmake -DPYTHON_VERSION=3.4 ..

That way, Ultimaker would be more open to accepting these modifications as pull requests because they wouldn't break any Ultimaker processes.
It would also make the configuration less dependent on a single version of Python and more open to supporting future versions.

Does that sound good?

CJ,

This would be perfect solution to be able to build with both Python revs. The version can be auto selected as the highest available. (i.e 3.4 and 3.5 )

cj added a comment.Feb 13 2017, 6:17 PM

I pushed up fixes to Cura2Build master, Cura2 dev, and Uranium dev. The Cura2 and Uranium patches will need to be merged by someone as a sign-off.

The only change in the Debian build process is the call to CMake will need an extra argument:

cmake -DMINIMUM_PYTHON_VERSION=3.4.0 ..

@alexei: By "auto selected as the highest available" do you mean the minimum requirement would be determined by the version of Python 3 installed on the build machine? If that's what you mean, a pull request with that would break Ultimaker's current build logic (which is hard coded to Python 3.5.0). Also, Debian Jesse comes with Python 3.4.2, which would mean the resulting deb package would not support Python 3.4.0. (We could hard code the required patch version to always be zero but that could be confusing and sometimes the patch version matters with Python and needs to be specified beyond zero.)

CJ,

I meant in Cura2Build if no -DMINIMUM_PYTHON_VERSION provided, the make script looks what installed on the system, and if 3.5 is installed it builds with 3.5 and if 3.4 is installed it builds with 3.4. If none of 3.4 or 3.5 installed, it will give an error.

CJ,

Also, since master branch is broken ATM anyway I would push all the changes to it too, not only to dev.

cj added a comment.Feb 14 2017, 10:57 AM

@alexei: For the present I have taken responsibility for Cura2Build and will push to its master branch. But in the case of the other two repositories, I am an external contractor pushing breaking changes to repositories that I am not responsible for. The fact that the repositories are already broken should reinforce the need for accountability, not remove it.

@cj: you can push to the Cura2 and Uranium repositories, just push your changes to a separate branch than master, then you can request a review using phabricator's Audit system (or just poke me) so it can be reviewed then merged into the master.

cj added a comment.Feb 14 2017, 1:08 PM

@kakaroto: From the documentation it looks like all I need to do is add you as an auditor, so I added you as an auditor to the two commits. If there's more I need to do to start the review process let me know.

kakaroto renamed this task from Debian Jessie Build to Figure out the QT 5.6/Python 3.5 bump.Feb 16 2017, 2:26 PM

Thanks @cj, I've reviewed the commits and it looks good, so it's fine. There's just one issue for me and it's "why was this bumped ?"
What I could find is these 2 commits : 53570e0aa0590578ec17f28a60335cd05c208223 and ba0fba08444746a6952508d58bc8c03312eeb48d but they don't explain why it had to happen, and they only seem to reference this "CURA-2150 " issue but it's not a github issue, and I think it's for cura's internal/private bug tracker.
I've filed an issue with them to have more information : https://github.com/Ultimaker/Cura/issues/1433
We'll have to wait and see what they answer before we can release cura2 on 3.4 dependency, otherwise we won't know what might blow up in our face.
I've changed the title of this task and will keep it open for now until we have more information.

So, to summarize the response from upstream (issue 1433) is that PyQT had to be updated because of the bug where it was constantly freezing and the cura build repo had a custom patch applied into the pyqt that it was building, so bumping the version was needed, and they bumped the python version because of the type hinting feature which was added in 3.5, and also to avoid issues with pyqt, numpy and other dependencies which usually have little support for older versions of python (according to them).
@cj how is your progress with building python 3.5 and integrating it in the deb ? Did you hit any problems ? If yes, what are they and maybe we can help.

cj added a comment.EditedFeb 21 2017, 4:13 PM

This is a busy week for me and I haven't had much time to work on the Python packaging. My understanding from the meeting Friday was the plan was to use Python 3.4 on Linux for now, and switch to Python packaging in the near future. Now Python 3.4 isn't an option and the Python packaging is more urgent.

With my current workload I wouldn't be able to finish this task until next week at the earliest. To have this task finished sooner it would need to be reassigned.

@cj, no, you misunderstood, python 3.4 is still an option since the python type hinting of 3.5 is backward compatible to 3.4. It's not any more urgent today than it was last Friday. I was just asking on your progress and on whether you had any issues.

kakaroto renamed this task from Figure out the QT 5.6/Python 3.5 bump to Package python 3.5 with cura.Feb 22 2017, 9:54 AM
kakaroto reassigned this task from kakaroto to cj.
kakaroto added a subscriber: kakaroto.
cj added a comment.Feb 22 2017, 10:17 AM

Okay, cool. I may have some questions about folder structure and where the installation should place files when I get to that part.

Building the python is a part of Cura2build now.

alexei closed this task as Resolved.Apr 19 2017, 7:14 AM