qtvcp needs testing with python3

[rene-dev]

qtpyvcp needs testing with python3, this should be an easy task.
running 2to3 -w should get most of the syntax problems fixed.

[c-morley]

Ok Rene sounds good.- i'll try to get to this soon.

[TurBoss]

Hello
Tested latest master today and managed to fix the rules
got every thing to work

Thank you so much !

[TurBoss]

well having some issues but fixing them

[TurBoss]

https://github.com/kcjengr/qtpyvcp/tree/Python3

installs with

pip install --upgrade -e .

[TurBoss]

hello,

managed to fix more errors but got a strange message on file load maybe from canon

PYTHON: exception during 'this' export:
ImportError: 'interpreter' is not a built-in module

[TurBoss]

[dwrobel]

managed to fix more errors but got a strange message on file load maybe from canon

PYTHON: exception during 'this' export:
ImportError: 'interpreter' is not a built-in module

There is a separate issue #825 for that.

[TurBoss]

managed to fix more errors but got a strange message on file load maybe from canon

PYTHON: exception during 'this' export:
ImportError: 'interpreter' is not a built-in module

There is a separate issue #825 for that.

Thanks

[rene-dev]

this PR started: #934

[satiowadahc]

@rene-dev Am I misunderstanding that qtpyvcp and qtvcp aren't quite the same thing? Should a separate issue be made for each? or should this one be re-titled to qtvcp and let the qtpyvcp project handle its own issue?

[rene-dev]

I cannot answer this question, I never used any QT stuff in linuxcnc.

[TurBoss]

I can port this to python3 but sadly i can't keep it working for python 2 and 3 at the same time

[rene-dev]

my proposal would be to update to python3 in master, the next release after 2.8 cannot realistically support python2.
If QT works with python3, why not use it in master.

[c-morley]

qtpyvcp is a separate project. I don't think this is the place to work on their problems unless it's something reasonable they need different in linuxcnc to function.

as for python3 and qtvcp - I agree python3 only for master as soon as I can get it to function/test a bit. (which shouldn't be long)

[rene-dev]

ah, I didnt know that. why do we need 2 qt python implementations? how do they differ?
This issue was intended for the one that is bundled with linuxcnc.

[satiowadahc]

If I understand it right qtvcp uses gtk signalling and qtpyvcp uses well qt signalling.

[c-morley]

Is there a way to detect what version of python linuxcnc was compiled with? Maybe an environment variable.
I would like to have qtvcp work with both versions if possible.

[rene-dev]

on an release version Im not aware how.
I dont recommend to bother with python2, its EOL since 9 Months, and new distros do not even have any python2 packages.
lets direct all the resources we have to the future.

[andypugh]

It seems that you can look at the "magic number" in one of the pyc files:
https://stackoverflow.com/questions/7807541/is-there-a-way-to-know-by-which-python-version-the-pyc-file-was-compiled

[c-morley]

I really need to support both for a while. buster can be compiled with python2 support and of course people can use older distributions with master. If I add my python3 only code to qtvcp now, I break peoples configs.
I don't think the burden to support both is too bad, but I need an easy way to check which version.
an environmental variable set would work fine.
There has got to be a way to record the version of python used to compile with.

[c-morley]

andypugh: I'll see if I can make that technique work - thanks

[andypugh]

We can make Python3 a dependency for Master. All supported platforms have it available.

[c-morley]

The problem isn't that python3 isn't available, it's that its an all or nothing deal. Right now if you use python2 everything works. Not true for python3 yet and you can't run both at the same time.

[rene-dev]

What doesn't work with python3? Switching python versions doesn't necessarily break a configuration. We need to make the switch at some point.

[c-morley]

I believe gladevcp, isn't converted yet?
if that is still true, then switching python versions will break configs if you use gladevcp/gscreen/gmoccapy and qtvcp.
That includes using gladvcp panels in AXIS.
Will python remaps work in either python version without changes?

[rene-dev]

I have a branch where glade works, conveted to gtk3. All the widgets work(gremlin is still wip), its the gladevcp UIs that need work. Not much, probably a weekend per ui.

[c-morley]

well that confirms my point then.
Does the buldbot build binaries with python3 compiled in? I don't think so.
Are you ready to remove python2 from the build system?

My point is linuxcnc isn't completely python3 ready yet - and even when it is it will still likely break configs.
I don't want to break configs for no good reason until it is - if I can reasonably help it.

Anyways it seems i can get python version from code with if sys.version_info.major > 2:

[andypugh]

I think that the fact that Python2 is officially over, finsihed, dead and buried is a good enough reason to abandon it.

I think we should announce that Master / 2.9 will be Py3 only. At that point you can stop trying to support Py2 in Master.

I am not expecting 2.9 to be 7 years after 2.8. I wouldn't be surprised if it is nearer 6 months. Master is probably more releasable now than 2.8 was a year ago.

[c-morley]

Well when master can actualy be python3 only that could make some sense.
It's the chicken and an egg thing. I'm not merging python3 only qtvcp until linuxcnc fully supports python3.
but i will merge it when it supports both - then i can continue to develop and it doesn't break configs for people that use python2.

I don't really understand the problem with python2 - we have buster so it can support both so the work has already been done.
Now that the work for python3 is almost done then on the next distribution you would not have to do the work for python2 because oython3 work is done and well tested.
At least at the moment i don't see the reason to break configs for master in buster.

In the time we have discussed this i have the principal parts of qtvcp working on python2 and python3 - it's really not that hard.

I think 6 months for master this time is too fast actually. - well I guess it depends on when the six months starts from :)

[andypugh]

The 6 months starts now. The 2.8 release is uploading now.

[gmoccapy]

Hallo Chris,I think we will need to do the switch to python 3 in a strong way. I tried to stay compatible between the releases 1 ; 2 and 3 of gmoccapy, but I found out quite fast, that it does not work out due to some very small changes. That is exactly the reason, why I decided to not take care about users configs. If someone changes on purpose the release (i.e. from 2.8 to master) he must be aware, that confics etc will not run any more.I will convert gmoccapy as soon as possible to use python 3 and also glade 3. I am pretty sure this change will brake a lot of confics. With that conversion I will announce, that there is no more support for gmoccapy 2 and gmoccapy 3 will only get bug fixes. All effort will be on the new python 3 release.I recommend to not put any effort in Python 2 projects.NorbertVon meinem Huawei-Tablet gesendet-------- Ursprüngliche Nachricht --------Von: c-morley <notifications@github.com>Datum: Fr., 4. Sep. 2020, 21:50An: LinuxCNC/linuxcnc <linuxcnc@noreply.github.com>Cc: Subscribed <subscribed@noreply.github.com>Betreff: Re: [LinuxCNC/linuxcnc] qtvcp needs testing with python3 (#819) well that confirms my point then. Does the buldbot build binaries with python3 compiled in? I don't think so. Are you ready to remove python2 from the build system? My point is linuxcnc isn't completely python3 ready yet - and even when it is it will still likely break configs. I don't want to break configs for no good reason until it is - if I can reasonably help it. Anyways it seems i can get python version from code with if sys.version_info.major > 2: —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[c-morley]

As soon as master is actually python3 only then qtvcp will be python3 only and I'll be happy about it.
The burden for python2 and 3 has not (so far anyways) been too much.
Things in linuxcnc seem to always to take much longer then we like.

As I mentioned I don't believe buildbot even produces python3 binaries - so why would I make qtvcp unusable until they do?

[rene-dev]

buildbot does run the test with python3, but no packages currently.
http://buildbot.linuxcnc.org/buildbot/builders/1660.rip-buster-python3

sys.version_info.major does give you the version of the interpreter is running, not the version linuxcnc was compiled with. important difference, you cant load linuxcnc/hal modules compiled in one version in another version!

yes there are still some problems, but we might as well fix them now, and not in 2 years.

[gmoccapy]

Chris, I did not recommend to destroy anything, but make 2.8 work with python 2 and 2.9 only with Python3. For sure we will need to support both for some time. Gmoccapy 3 will get support till we launch 2.9, or may be 3.0 (jumping the 2.9 release may make sense to demonstrate also the big changes) and after the release I will only fix bugs in that gui. The new gui should be ready with the next release and will only work with python3NorbertVon meinem Huawei-Tablet gesendet-------- Ursprüngliche Nachricht --------Von: c-morley <notifications@github.com>Datum: Sa., 5. Sep. 2020, 10:21An: LinuxCNC/linuxcnc <linuxcnc@noreply.github.com>Cc: Norbert Schechner <nieson@web.de>, Comment <comment@noreply.github.com>Betreff: Re: [LinuxCNC/linuxcnc] qtvcp needs testing with python3 (#819) As soon as master is actually python3 only then qtvcp will be python3 only and I'll be happy about it. The burden for python2 and 3 has not (so far anyways) been too much. Things in linuxcnc seem to always to take much longer then we like. As I mentioned I don't believe buildbot even produces python3 binaries - so why would I make qtvcp unusable until they do? —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[satiowadahc]

Now following versioning systems a complete break of the program is a major change. And typically versioning in major.minor.patch. So in that effect, is master going to python 3 only not a major change and should be going to 3.0.0 as well?

[rene-dev]

most minor versions broke configs so far. just changing python version doesn't necessarily break configs. master cant be relied on anyway.

[simaoamorim]

@rene-dev, @satiowadahc has a point, if a new version is not backwards compatible, then the major version should be increased (see https://semver.org/ and specifically https://semver.org/#how-should-i-handle-deprecating-functionality).

The fact that minor version bumps have broken configs so far is a kind of a red flag for any user without deep linuxcnc knowledge, because upgrading minor versions should be done in an incremental manner.
For instance, upgrading from 2.7.x to 2.8.x shouldn't need any changes to configurations, and any configuration that worked in 2.7.x should work out-of-the-box in 2.8.x, knowing that you just wouldn't use any new features implemented in 2.8 (I don't know if this upgrade breaks configs or not, just using it as an example).

Now, adding python3 support can be an incremental change if both versions are supported at the same time, meaning you can have scripts written for py2 and py3 and the same time in the linuxcnc universe, but as soon as you remove python2 support, you're breaking the incremental changes and so I agree with @satiowadahc, linuxcnc should move to version 3.0 at that point.

[rene-dev]

thats not how linuxcnc versions used to work in the past, most versions where the second number changed required config changes, the last number was bugfixing only.
back to topic, my arguments are:

• master cannot be expected not to break configs, thats where the changes are happening
• just changing the python and gtk version doesn't break configs, unless you have custom UI or python stuff.

[andypugh]

The "2" is a reference to EMC2, and I anticipate it will always be there. :-)

[c-morley]

I think the version of emc was set to 2 when HAL was added. Which seems a very good reason to raise the major version.
It could be argued mandating python 3 could be a valid reason too. Python is used extensively in linuxcnc.

Qtvcp works with python2 and 3 now, depending on how linuxcnc is compiled.
I think you can close this issue - any future problems found can be opened separately.

[rene-dev]

I tested it today, and all seems to work fine. Thanks!