Closed hroncok closed 6 years ago
Yeah, help on this will be extremely welcome. But an important point is that wxpython4 is not fully compatible with wxpython3.x, so we'll be doing a double port. This is made more difficult by the fact that the wxpython maintainers have decided to remove wxpython3.x from the pip repositories.
I think if the py3 port works correctly, there's no reason to maintain py2 compatibility in the medium term - older versions can be used with py2.7 if necessary.
On 07.02.2018 19:33, Miro Hrončok wrote:
I've just noticed that wxPython 4 with Python 3 support was released :tada:
All other deps should be Python 3 ready. Can we start porting this to Python 3? I can offer help, however I would like to know if this would be accepted and whether we want to port to Python 3 only or to maintain Python 2 compatibility.
(I wasn't monitoring Printrun closely lately, so if this discussion already happened somewhere else, sorry about that.)
Added a roadmap to the first post.
Hi, I would also be willing to help port Printrun to Python 3 and wxPython 4 :).
@rockstorm101 How's your wxPython? I'd rather port to Python 3 once this is already ported to Phoenix...
Hi @hroncok,
How's your wxPython?
wxPython 4 is not yet in Debian but I believe the current maintainer is already working on it. So I'll be able to play around with it soon.
I'd rather port to Python 3 once this is already ported to Phoenix...
Sounds good to me. I haven't started doing anything related to this, but it seems like a lot of rewriting is going to be needed. And if so, it might be easier to rewrite with python 3 already in mind.
I would suggest going for a "Printrun 2.x" which would support Python 3 and wxPython 4. I agree with @kliment, since Python 2 will be deprecated in two years, it makes no sense to worry about making it compatible with Python 2. And maybe maintain current "Printrun 1.x" until this Python 2 disappearance is finally official.
Note that I'm fixing tracebacks that keep occurring with new wxPython and will post a PR soon.
wxPython 4 is ready for review at PR #886, Python 3 builds on top of it in PR #887. Metadata+docs are also in the later PR.
Great! Thanks for your work @hroncok, I'll try it as soon as I can.
wxPython 4 is not yet in Debian but I believe the current maintainer is already working on it. So I'll be able to play around with it soon.
Yes, it's sitting in the Debian NEW queue (I'm packaging it there too). I suspect it will probably make it into Fedora sooner though. :-)
@rockstorm101 I would like to get this to Fedora 28. Anything I can do to help this move forward?
So am I correctly understanding this only now depends on wxpython 4 being packaged?
HI @hroncok, how urgent would this be? I'm sorry, I haven't been able to test this yet. In order to package Printrun for Fedora, do you simply need the changes to be merged or do you need a tagged release?
@kliment Well I don't think it needs wxpython 4 to be packaged at all. A new release of Printrun will be done, anybody can run it with pip installed dependencies straight away (as described in the README in that PR). Distros will pick the new release once they have the new dependency (wxpython4 packaged). In Fedora, that can be done now for Fedora 28+.
@rockstorm101 In ideal word a tagged release. However maybe if it just gets merged, we can wait to spot problems before an actual release is made.
Hi @hroncok, I haven't been able to print anything but I managed to run the application. However I get some nasty output:
Generating grammar tables from /usr/lib/python3.6/lib2to3/Grammar.txt
Generating grammar tables from /usr/lib/python3.6/lib2to3/PatternGrammar.txt
Which even though they seem harmless I believe it is unwanted. And this ones:
12:40:24: Debug: Unsupported OpenGL attribute 170972752
12:40:24: Debug: Unsupported OpenGL attribute 170972752
12:40:24: Debug: Unsupported OpenGL attribute 42
12:40:24: Debug: Unsupported OpenGL attribute 170972872
12:40:24: Debug: Unsupported OpenGL attribute 170972872
12:40:24: Debug: Unsupported OpenGL attribute 170972872
12:40:24: Debug: Unsupported OpenGL attribute 47
12:40:24: Debug: Unsupported OpenGL attribute 170972792
12:40:24: Debug: Unsupported OpenGL attribute 170972792
12:40:24: Debug: Unsupported OpenGL attribute 170972792
12:40:24: Debug: Unsupported OpenGL attribute 48
12:40:24: Debug: Unsupported OpenGL attribute 170972832
12:40:24: Debug: Unsupported OpenGL attribute 170972832
12:40:24: Debug: Unsupported OpenGL attribute 170972832
12:40:24: Debug: Unsupported OpenGL attribute -1403674432
12:40:24: Debug: Unsupported OpenGL attribute 49
Which might be due to how I installed pyglet and wxPython.
Do you suffer any of this? Could it be that you have any clue as of how to fix them?
Side notes from a maintainer perspective :P:
Generating grammar tables from /usr/lib/python3.6/lib2to3/Grammar.txt Generating grammar tables from /usr/lib/python3.6/lib2to3/PatternGrammar.txt
This can hardly have to do anything with Printrun. I didn't invoke 2to3 in any way. Maybe it's your python3 setup?
The Unsupported OpenGL attribute
s are there right from when i ported to wxPython 4. No idea where they come from but they seem harmless.
As for pyglet, I've installed it to venv as described in the README. (However I have python2-pyglet
RPM installed on my system, so all the non-python requirements it has are already installed.) I had no troubles there juts run python -m pip install -r requirements.txt
(that includes pyglet). Could you give me the output of this:
$ python3.6 -m venv __venv__ && . __venv__/bin/activate
$ python -m pip install pyglet
?
Also, yes Fedora has python3-pyglet
packaged.
Those Unsupported OpenGL attribute
are coming from wxWidgets. I'm assuming you did not get those with wxPython 3? If not, then it could be a bug in wxPython 4. Can you tell me how to reproduce that error with your branch?
@swt2c https://github.com/kliment/Printrun/tree/2.x#use-python-virtual-environment
I'm assuming you did not get those with wxPython 3?
Exactly.
@rockstorm101 Another good idea might be to release 2.0.0rc1
Generating grammar tables from /usr/lib/python3.6/lib2to3/Grammar.txt Generating grammar tables from /usr/lib/python3.6/lib2to3/PatternGrammar.txt
This can hardly have to do anything with Printrun. I didn't invoke 2to3 in any way. Maybe it's your python3 setup?
Yeah, it is probably my setup. For now I'm going to blame the future package, which is a dependency of pyglet.
As for pyglet, I've installed it to venv as described in the README.
I haven't been able to run Printurn 2 via python virtual evironment due to the lack of 32bit wheels of wxPython 4. But, recompiling it using python 3 worked and it did not break Printrun 1.x.
Another good idea might be to release 2.0.0rc1
Agree, creating an RC would be the way to go. Should #890 be fixed first? It won't affect upgrades but will affect new installations.
Okay, so the Unsupported OpenGL attribute
only show up in debug builds of wx, which the Fedora build is not, so that explains why I didn't see them initially. The wheel builds are apparently debug builds.
In any event, this does appear to be a bug, or at the very least an undocumented API change. I'm finding out what Robin wants to do about it.
Okay, so the Unsupported OpenGL attribute only show up in debug builds of wx, which the Fedora build is not, so that explains why I didn't see them initially. The wheel builds are apparently debug builds.
In any event, this does appear to be a bug, or at the very least an undocumented API change. I'm finding out what Robin wants to do about it.
The debug warnings should be fixed upstream. I'll cherry-pick the patch into Fedora if Robin doesn't do a new release in the near future.
Awesome! Thank you.
Closing this, as it's ready in 2.x
I've just noticed that wxPython 4 with Python 3 support was released :tada:
All other deps should be Python 3 ready. Can we start porting this to Python 3? I can offer help, however I would like to know if this would be accepted and whether we want to port to Python 3 only or to maintain Python 2 compatibility.
This can be split in several subtasks (will edit to add more granularity):
setup.py
,README
... with metadata/information