3D view broken in own-compiled package, Debian repo version is good -- part deux!

Question

3D view broken in own-compiled package, Debian repo version is good -- part deux!

VanessaE opened this issue a year ago · 33 comments

Using Debian Bookworm, which comes with Python 3.11

I tried to do a new build on a cleanly-installed system, but ran into trouble again. The build itself appeared to go okay, as there were no obvious errors or warnings, but when I try to run the result, the 3d view doesn't work.

This happens whether I point pronterface to my config or not (it has a unique filename, so if I don't point it there it'll use the defaults).

The program automatically falls back to 2d, with these errors:

(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose

(pronterface.py:45465): Gtk-WARNING **: 20:45:08.798: Theme parsing error: gtk-widgets.css:80:34: Expected a valid selector

(pronterface.py:45465): Gtk-WARNING **: 20:45:08.799: Theme parsing error: gtk-widgets.css:979:19: '' is not a valid color name
INFO:root:Loading config file /home/vanessa/.config/Printrun/pronsolerc
DEBUG:root:set last_window_maximized False
DEBUG:root:set last_window_width 1276
DEBUG:root:set last_window_height 1440
DEBUG:root:set last_file_path /home/vanessa
DEBUG:root:set recentfiles ["/home/vanessa/.pronsolerc-2.x-small-HC"]
3D view mode requested, but we failed to initialize it.
Falling back to 2D view, and here is the backtrace:
NotImplementedError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/home/vanessa/RepRap/Printrun/printrun/gui/viz.py", line 70, in __init__
    root.gviz = printrun.gcview.GcodeViewMainWrapper(
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vanessa/RepRap/Printrun/printrun/gcview.py", line 374, in __init__
    self.glpanel = GcodeViewPanel(parent, realparent = self,
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/vanessa/RepRap/Printrun/printrun/gcview.py", line 86, in __init__
    super().__init__(parent, wx.DefaultPosition,
  File "/home/vanessa/RepRap/Printrun/printrun/gl/panel.py", line 90, in __init__
    self.canvas = glcanvas.GLCanvas(self, wx.ID_ANY, attribList, pos, size, style)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SystemError: <class 'wx._glcanvas.GLCanvas'> returned a result with an exception set

These errors seem suspiciously similar to #1389, but requirements.txt already has the change mentioned there, so that isn't it.

Steps to reproduce: er... install a clean Debian Bookworm system and try to build pronterface per the instructions at https://github.com/kliment/Printrun#linux--macos .

If it matters, I did not have to install the out-of-index wxPython wheel, as the build process automatically brought in and compiled wxPython-4.2.1 without any issues.

Answer 1 · 2023-11-02T22:20:24.000Z

Hmm, seemingly wxPython fails to create the GLCanvas.
And 2.0.0~rc8 from the repo has a working 3D view?

Could it be that the wxPyton that you compiled is missing the wx.glcanvas module? Or maybe this module failed and the rest finished normally.
Also, I'm not using debian myself, but Printrun 2.0.1 is in the 'unstable' section of debian packages. Does the 3D view work in that?

Answer 2 · 2023-11-02T23:49:26.000Z

And 2.0.0~rc8 from the repo has a working 3D view?

Yep, it works perfectly in that regard. The repo build has some stylistic issues, but those don't impact the 3d view.

Could it be that the wxPyton that you compiled is missing the wx.glcanvas module? Or maybe this module failed and the rest finished normally.

No clue there. I didn't see any errors during the build, but in all fairness there was a LOT of spew.

Does the 3D view work in [2.0.1 from unstable]?

Dunno, I've had relatively poor luck in the past trying to mix stable with unstable, so I just don't do it anymore.

Answer 3 · 2023-11-03T09:56:18.000Z

Hi,
Printrun v2.0.0RC8 (and all other RC versions) are known to have serious problems with wxPython. If I remember correct there was a lot of compatibility problems especially with different Linux versions and distros (e.g #1283) as well. In addition there were changes in the GUI for 3D view that need to have a minimum version of wxPython >= 3.1 and those wasn't really successful with all the distros versions and also well known in the wxPython forum.

Question, why do you not use the actual Pronterface version in combination with wxPython 4.2.1? (I mention this version especially because this version seems to be the most stable version since long time over all supported operating systems)
In addition there were some problems with Python 3.11 as well and this was why we didn't recommend Python 3.11 in the past.

Long story short, don't use any Printrun v2.0.0 release candidate versions.
We did a lot of adjustments along the way dealing with all the wxPython versions below 4.1 (and issues around them) in combination with all the supported operating systems and it wasn't a very successful time and experience. This was the main reason why there wasn't a official Pronterface version 2.0 for a long time (>2 years).

Side mark: I was tinkering the last days on some tests with wxPython regarding a Windows x32 version of Pronterface as wxPython now have x32 support again with version 4.2.1 only. This version as well do not work out of the box and you need to restrict at least one the library (Pillow) to an older version. The actual version(s) do not support x32 any longer. In the end I got it to compile, , running and tested today with Python 3.11.6 (but not tested for older versions of python so fare). But I'm not sure if I really want to make a official version because for now I have no clue if this will work for all other operating systems too or what else issues in addition will pop up then. Is it worth doing it? I don't know...

Answer 4 · 2023-11-03T10:56:24.000Z

why do you not use the actual Pronterface version in combination with wxPython 4.2.1?

I'll wear my Debian maintainer hat here. The reason why 2.0.0rc8 is the last package available in Debian stable is because I could not push the 2.0.1 version of Printrun due to pyglet being > 2.0 for the next release of Debian. So unless we solve the pyglet incompatibility (see #1291), Debian/Ubuntu users will need to install from source from now on to get the very latest Printrun as suggested here. (Printrun is no longer packaged for Ubuntu since 23.10 and Debian 13 won't have it either)

Answer 5 · 2023-11-03T11:03:37.000Z

Good point, I missed that already ...

Answer 6 · 2024-01-12T08:50:51.000Z

I decided to try again today, fresh clone of Pronterface (commit 69bed06), and something is... not right -- but at the same time, something is WORKING unexpectedly.

The first time I tried to run it, the result was worse than before -- the part of the window where the 2d/3d view should be just showed a copy of whatever was under the window at the moment it started, and if I rolled/unrolled the window or minimized/restored it, that area changed to show whatever's under the window at that moment.

There was no meaningful output in the terminal. Not even a warning about the 3d view, nor anything about falling back to 2d mode.

Then played around a bit, trying a couple of variations, just to make absolutely sure I didn't do anything wrong. On the third try, for no immediately-obvious reason, it worked just fine!

And then I realized: On that run, I had launched another terminal after closing a few others (just reducing clutter on my desktop), and ran Pronterface from there, but forgot to enable the venv there beforehand. The GUI seemed completely normal and 3d view worked. I even loaded some gcode and it seemed just fine! Here's the output from such a run:

vanessa@rainbird:~$ cd RepRap/Printrun/
vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose
INFO:root:Loading config file /home/vanessa/.config/Printrun/pronsolerc
DEBUG:root:set last_window_maximized False
DEBUG:root:set last_window_width 1050
DEBUG:root:set last_window_height 720

So apparently something is being written or copied to the venv wrongly when it's being created. But what? And why should I even be using a venv if it runs correctly without one?

Here's the install spew:

vanessa@rainbird:~$ cd RepRap/
vanessa@rainbird:~/RepRap$ rm -rf Printrun/
vanessa@rainbird:~/RepRap$ git clone https://github.com/kliment/Printrun.git
Cloning into 'Printrun'...
remote: Enumerating objects: 13210, done.
remote: Counting objects: 100% (730/730), done.
remote: Compressing objects: 100% (315/315), done.
remote: Total 13210 (delta 466), reused 613 (delta 398), pack-reused 12480
Receiving objects: 100% (13210/13210), 81.03 MiB | 13.18 MiB/s, done.
Resolving deltas: 100% (8332/8332), done.
vanessa@rainbird:~/RepRap$ cd Printrun
vanessa@rainbird:~/RepRap/Printrun$ python3 -m venv venv
vanessa@rainbird:~/RepRap/Printrun$ source venv/bin/activate
(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 -m pip install -r requirements.txt
Ignoring pillow: markers 'sys_platform == "win32"' don't match your environment
Ignoring pyobjc-framework-Cocoa: markers 'sys_platform == "darwin"' don't match your environment
Ignoring pyreadline3: markers 'sys_platform == "win32"' don't match your environment
Collecting pyserial>=3.0
  Using cached pyserial-3.5-py2.py3-none-any.whl (90 kB)
Collecting wxPython>=4.2.0
  Using cached wxPython-4.2.1.tar.gz (73.7 MB)
  Preparing metadata (setup.py) ... done
Collecting numpy>=1.8.2
  Using cached numpy-1.26.3-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (18.3 MB)
Collecting pyglet<2.0,>=1.1
  Using cached pyglet-1.5.28-py3-none-any.whl (1.1 MB)
Collecting psutil>=2.1
  Using cached psutil-5.9.7-cp36-abi3-manylinux_2_12_x86_64.manylinux2010_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (285 kB)
Collecting lxml>=2.9.1
  Using cached lxml-5.1.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (8.1 MB)
Collecting appdirs>=1.4.0
  Using cached appdirs-1.4.4-py2.py3-none-any.whl (9.6 kB)
Collecting dbus-python>=1.2.0
  Using cached dbus_python-1.3.2-cp311-cp311-linux_x86_64.whl
Collecting pillow
  Using cached pillow-10.2.0-cp311-cp311-manylinux_2_28_x86_64.whl (4.5 MB)
Collecting six
  Using cached six-1.16.0-py2.py3-none-any.whl (11 kB)
Installing collected packages: pyserial, pyglet, appdirs, six, psutil, pillow, numpy, lxml, dbus-python, wxPython
  DEPRECATION: wxPython is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559
  Running setup.py install for wxPython ... done
Successfully installed appdirs-1.4.4 dbus-python-1.3.2 lxml-5.1.0 numpy-1.26.3 pillow-10.2.0 psutil-5.9.7 pyglet-1.5.28 pyserial-3.5 six-1.16.0 wxPython-4.2.1
(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 -m pip install Cython
Collecting Cython
  Using cached Cython-3.0.8-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (3.6 MB)
Installing collected packages: Cython
Successfully installed Cython-3.0.8
(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 setup.py build_ext --inplace
Compiling printrun/gcoder_line.pyx because it changed.
[1/1] Cythonizing printrun/gcoder_line.pyx
running build_ext
building 'printrun.gcoder_line' extension
creating build
creating build/temp.linux-x86_64-cpython-311
creating build/temp.linux-x86_64-cpython-311/printrun
x86_64-linux-gnu-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -fPIC -I/home/vanessa/RepRap/Printrun/venv/include -I/usr/include/python3.11 -c printrun/gcoder_line.c -o build/temp.linux-x86_64-cpython-311/printrun/gcoder_line.o
creating build/lib.linux-x86_64-cpython-311
creating build/lib.linux-x86_64-cpython-311/printrun
x86_64-linux-gnu-gcc -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g -fwrapv -O2 build/temp.linux-x86_64-cpython-311/printrun/gcoder_line.o -L/usr/lib/x86_64-linux-gnu -o build/lib.linux-x86_64-cpython-311/printrun/gcoder_line.cpython-311-x86_64-linux-gnu.so
copying build/lib.linux-x86_64-cpython-311/printrun/gcoder_line.cpython-311-x86_64-linux-gnu.so -> printrun
(venv) vanessa@rainbird:~/RepRap/Printrun$

It took a bit of time to build wxPython, maybe 10 minutes (I didn't time it).

Answer 7 · 2024-01-14T09:46:52.000Z

I decided to try again today, fresh clone of Pronterface [...] the part of the window where the 2d/3d view should be just showed a copy of whatever was under the window at the moment it started, and if I rolled/unrolled the window or minimized/restored it, that area changed to show whatever's under the window at that moment.

There was no meaningful output in the terminal. Not even a warning about the 3d view, nor anything about falling back to 2d mode.

[...] On the third try, for no immediately-obvious reason, it worked just fine! [...] On that run, I [...] ran Pronterface from there, but forgot to enable the venv there beforehand. The GUI seemed completely normal and 3d view worked.

Hi @VanessaE, thank you for your detailing your findings. Would you mind sharing the output of reportbug --template pronterface in your Bookworm system? Only the part where it says "Versions of packages pronterface depends on" really. Two thoughts come to mind:

The combination of dependencies installed by the package manager works while the one installed via pip install -r requirements.txt doesn't. Hence why I'm trying to find the mismatch.
Or, dependencies installed via Debian's repositories are configured in a way which is better suited to fit your system/GPU/window-server configuration.

I confirm I can reproduce the behavior you describe. In my machine, when running from source, I followed your steps and found the same issue where the 2D/3D view did not work and showed the background instead. Installing pyglet 2+ inside the virtual environment via python3 -m pip install -v "pyglet>2" made the 2D/3D view work again though only in 2D mode (as expected) throwing an import error on pyglet.gl. Could you please try to confirm that this behaves the same for you?

Answer 8 · 2024-01-14T10:33:06.000Z

reportbug --template pronterface

...returns Unable to identify a valid from address, please run 'reportbug --configure' which makes sense, since I've never set that up (it asks too many questions). However, I can get the output you want with a quick one-liner:

(venv) vanessa@rainbird:~/RepRap/Printrun$ for i in $(apt-cache depends pronterface|cut -f 2 -d ":"|grep -v "<"|sort|uniq); do echo -n $i " -- "; apt-cache show $i |grep Version; done
printrun  -- Version: 2.0.0~rc8-2
pronsole  -- Version: 2.0.0~rc8-2
pronterface  -- Version: 2.0.0~rc8-2
python3  -- Version: 3.11.2-1+b1
python3-cairosvg  -- Version: 2.5.2-1.1+deb12u1
python3-gi  -- Version: 3.42.2-3+b1
python3-libxml2  -- Version: 2.9.14+dfsg-1.3~deb12u1
python3-numpy  -- Version: 1:1.24.2-1
python3-pyglet  -- Version: 1.5.27+ds-2
python3-wxgtk4.0  -- Version: 4.2.0+dfsg-3
slic3r  -- Version: 1.3.0+dfsg1-5+b2

Or, dependencies installed via Debian's repositories are configured in a way which is better suited to fit your system/GPU/window-server configuration.

I kinda doubt it, since Debian is, as far as I know, pretty generic in that regard.

Installing pyglet 2+ inside the virtual environment via python3 -m pip install -v "pyglet>2" made the 2D/3D view work again though only in 2D mode (as expected)

Yep, I can reproduce this behavior too, and terminal output looks like I'd expect:

(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose
INFO:root:Loading config file /home/vanessa/.config/Printrun/pronsolerc
DEBUG:root:set last_window_maximized False
DEBUG:root:set last_window_width 1050
DEBUG:root:set last_window_height 720
3D view mode requested, but we failed to initialize it.
Falling back to 2D view, and here is the backtrace:
Traceback (most recent call last):
  File "/home/vanessa/RepRap/Printrun/printrun/gui/viz.py", line 69, in __init__
    import printrun.gcview
  File "/home/vanessa/RepRap/Printrun/printrun/gcview.py", line 22, in <module>
    from .gl.panel import wxGLPanel
  File "/home/vanessa/RepRap/Printrun/printrun/gl/panel.py", line 28, in <module>
    from pyglet.gl import glEnable, glDisable, GL_LIGHTING, glLightfv, \
ImportError: cannot import name 'GL_LIGHTING' from 'pyglet.gl' (/home/vanessa/RepRap/Printrun/venv/lib/python3.11/site-packages/pyglet/gl/__init__.py)

Answer 9 · 2024-01-27T13:21:54.000Z

I guess you guys missed my earlier question: why should I use a venv if Pronterface runs correctly without one?

Answer 10 · 2024-01-28T09:22:29.000Z

python3-wxgtk4.0  -- Version: 4.2.0+dfsg-3

I failed to build a wxPython 4.2.0 wheel for Python 3.11 (stumbled upon wxWidgets/Phoenix#2296) and I couldn't find one online so I'm unable to try exactly the combination that (allegedly) works. I suspect it is the wxPython-pyglet combination that is to blame/thank but I can't prove it.

why should I use a venv if Pronterface runs correctly without one?

Oh no, please use whatever works best for you. It is sad but, as you found out, running from source with an venv has a broken 2D/3D view as of today so probably not the best thing to do on your system.

Answer 11 · 2024-01-28T09:28:48.000Z

Well since this combo works, perhaps that's a good enough reason to update the official Debian build and not worry about pyglet?

I mean, just use what's there like mine's doing now, and lock the version numbers of Pronterface's requirements according to the list I gave above?

Answer 12 · 2024-01-28T14:27:54.000Z

Well since this combo works, perhaps that's a good enough reason to update the official Debian build and not worry about pyglet?

If by "official Debian build" you mean the Printrun package at official Debian repositories, we (Debian maintainers) can't force the pronterface package to require pyglet < 2.0 and wxPython == 4.2.0 because that would break the next Debian release. Which is where virtual environments come handy, you can have any combination of dependencies for your program, regardless of the versions currently present in your system. Ideal scenario would be for Printrun to migrate to pyglet 2.x.

Answer 13 · 2024-08-05T01:19:36.000Z

The program is no longer willing to run at all without a virtual environment, like it would before. It throws these errors:

vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose -c /home/vanessa/.config/Printrun/pronsolerc-2.x-small-HC 
Traceback (most recent call last):
  File "/home/vanessa/RepRap/Printrun/pronterface.py", line 30, in <module>
    from printrun.pronterface import PronterApp
  File "/home/vanessa/RepRap/Printrun/printrun/pronterface.py", line 32, in <module>
    from . import pronsole
  File "/home/vanessa/RepRap/Printrun/printrun/pronsole.py", line 32, in <module>
    from platformdirs import user_cache_dir, user_config_dir, user_data_dir
ModuleNotFoundError: No module named 'platformdirs'

Run inside a venv as one is normally told to, and I still have the problem of a completely broken 3d view as described above.

When doing so, it also complains on the console about not finding Cython, even though I installed it as in the usual manner:

WARNING:root:Memory-efficient GCoder implementation unavailable: cannot import name 'gcoder_line' from 'printrun' (/home/vanessa/RepRap/Printrun/printrun/__init__.py)

I suppose that's another pyglet-related bug.

So as of this moment, Pronterface is completely broken. I had to restore the older build from my backup drive in order to continue what I was working on (protip: don't play around with upgrading while in the middle of a big project 😛 ).

What do I do now?

Answer 14 · 2024-08-05T08:15:39.000Z

Hi @VanessaE
What is your actual pyglet and wxPython version in venv and the actual Linux version?

Maybe I can help a little for the warning message. The warning for gcoder_line happens if building the printrun.gcoder_line extension fails when I remember correct.

For my installation I have 3 additional files after the building process runs successfully. Here is where the files are located for a Windows build (the last file should be named different depending on OS and python version).

c:\Users\Armin\source\repos\DivingDuck\Printrun\printrun\gcoder_heapy_support.patch
c:\Users\Armin\source\repos\DivingDuck\Printrun\printrun\gcoder_line.c
c:\Users\Armin\source\repos\DivingDuck\Printrun\printrun\gcoder_line.cp310-win_amd64.pyd

You can force building this with python setup.py build_ext --inplace, but this should be usually part of the building process python -m pip install . (please see https://github.com/kliment/Printrun?tab=readme-ov-file#running-from-source)
Not having the gcoder line extension should not harm Pronterface, because the fall back is to use the python version instead (what is then a little bit slower in processing).

For the first error, this should be a easy fix. Looks like you missed importing modules via requirements.txt, The module platformdirs is not available: ModuleNotFoundError: No module named 'platformdirs'
pip install platformdirs should fix this. Maybe a good idea to check for other missing modules too.
Edit: For reference #1426 and #1420, this is related to appdirs

Best regards,
DD

Answer 15 · 2024-08-05T09:38:22.000Z

I'm on Debian "Bookworm" 12.6. The install process shows pyglet at version 1.5.29, and wXpython is version 4.2.1 (and still no wheels, it has to be built).

Here's the entire build log... note that I cloned into a dir in /tmp and cleared my pip cache, doing my work there instead of my usual location.

You can also see the errors described in #1442:

Show build log...

vanessa@rainbird:/tmp$ git clone https://github.com/kliment/Printrun.git
Cloning into 'Printrun'...
remote: Enumerating objects: 13540, done.
remote: Counting objects: 100% (1060/1060), done.
remote: Compressing objects: 100% (430/430), done.
remote: Total 13540 (delta 644), reused 899 (delta 539), pack-reused 12480
Receiving objects: 100% (13540/13540), 81.41 MiB | 41.85 MiB/s, done.
Resolving deltas: 100% (8510/8510), done.
vanessa@rainbird:/tmp$ cd Printrun
vanessa@rainbird:/tmp/Printrun$ rm -rf ~/.cache/pip/
vanessa@rainbird:/tmp/Printrun$ python3 -m venv venv
vanessa@rainbird:/tmp/Printrun$ source venv/bin/activate
(venv) vanessa@rainbird:/tmp/Printrun$ python3 -m pip install -r requirements.txt
Ignoring pillow: markers 'sys_platform == "win32"' don't match your environment
Ignoring pyobjc-framework-Cocoa: markers 'sys_platform == "darwin"' don't match your environment
Ignoring pyreadline3: markers 'sys_platform == "win32"' don't match your environment
Collecting pyserial>=3.0
  Downloading pyserial-3.5-py2.py3-none-any.whl (90 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 90.6/90.6 kB 1.2 MB/s eta 0:00:00
Collecting wxPython>=4.2.0
  Downloading wxPython-4.2.1.tar.gz (73.7 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 73.7/73.7 MB 26.1 MB/s eta 0:00:00
  Preparing metadata (setup.py) ... done
Collecting numpy>=1.8.2
  Downloading numpy-2.0.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (19.5 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 19.5/19.5 MB 26.1 MB/s eta 0:00:00
Collecting pyglet<2.0,>=1.1
  Downloading pyglet-1.5.29-py3-none-any.whl (1.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 MB 23.0 MB/s eta 0:00:00
Collecting psutil>=2.1
  Downloading psutil-6.0.0-cp36-abi3-manylinux_2_12_x86_64.manylinux2010_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (290 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 290.5/290.5 kB 21.7 MB/s eta 0:00:00
Collecting lxml>=2.9.1
  Downloading lxml-5.2.2-cp311-cp311-manylinux_2_28_x86_64.whl (5.0 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.0/5.0 MB 24.1 MB/s eta 0:00:00
Collecting platformdirs
  Downloading platformdirs-4.2.2-py3-none-any.whl (18 kB)
Collecting dbus-python>=1.2.0
  Downloading dbus-python-1.3.2.tar.gz (605 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 605.5/605.5 kB 27.5 MB/s eta 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting pillow
  Downloading pillow-10.4.0-cp311-cp311-manylinux_2_28_x86_64.whl (4.5 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.5/4.5 MB 25.8 MB/s eta 0:00:00
Collecting six
  Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Building wheels for collected packages: dbus-python
  Building wheel for dbus-python (pyproject.toml) ... done
  Created wheel for dbus-python: filename=dbus_python-1.3.2-cp311-cp311-linux_x86_64.whl size=119821 sha256=75400ba10dfb0b6fc2b58abff47f9282927a8fec42a707dadd89ce9e71617534
  Stored in directory: /home/vanessa/.cache/pip/wheels/84/33/c2/bb34ffd273446cb228d2154aa702365159f5a7dcc5278584ce
Successfully built dbus-python
Installing collected packages: pyserial, pyglet, six, psutil, platformdirs, pillow, numpy, lxml, dbus-python, wxPython
  DEPRECATION: wxPython is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559
  Running setup.py install for wxPython ... /

[note: copy/paste error right here, I may have lost a couple of lines of the output, but it wouldn't have been important]

(venv) vanessa@rainbird:/tmp/Printrun$ python3 -m pip install Cython
Collecting Cython
  Downloading Cython-3.0.10-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (3.6 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 3.6/3.6 MB 3.1 MB/s eta 0:00:00
Installing collected packages: Cython
Successfully installed Cython-3.0.10
(venv) vanessa@rainbird:/tmp/Printrun$ python3 setup.py build_ext --inplace
Traceback (most recent call last):
  File "/tmp/Printrun/setup.py", line 66, in <module>
    setup(
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/__init__.py", line 108, in setup
    return distutils.core.setup(**attrs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/_distutils/core.py", line 159, in setup
    dist.parse_config_files()
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/dist.py", line 872, in parse_config_files
    pyprojecttoml.apply_configuration(self, filename, ignore_option_errors)
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/config/pyprojecttoml.py", line 62, in apply_configuration
    config = read_configuration(filepath, True, ignore_option_errors, dist)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/config/pyprojecttoml.py", line 140, in read_configuration
    return expand_configuration(asdict, root_dir, ignore_option_errors, dist)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/config/pyprojecttoml.py", line 195, in expand_configuration
    return _ConfigExpander(config, root_dir, ignore_option_errors, dist).expand()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/config/pyprojecttoml.py", line 243, in expand
    self._expand_all_dynamic(dist, package_dir)
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/config/pyprojecttoml.py", line 287, in _expand_all_dynamic
    self._obtain_entry_points(dist, package_dir) or {},
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/config/pyprojecttoml.py", line 361, in _obtain_entry_points
    text = self._obtain(dist, "entry-points", package_dir)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/config/pyprojecttoml.py", line 331, in _obtain
    self._ensure_previously_set(dist, field)
  File "/tmp/Printrun/venv/lib/python3.11/site-packages/setuptools/config/pyprojecttoml.py", line 307, in _ensure_previously_set
    raise OptionError(msg)
distutils.errors.DistutilsOptionError: No configuration found for dynamic 'entry-points'.
Some dynamic fields need to be specified via `tool.setuptools.dynamic`
others must be specified via the equivalent attribute in `setup.py`.

For comparison, Debian's build of Pronterface 2.0.0-rc8 from the repository uses pyglet 1.5.27 and wxpython 4.2.0 (I think). Note that I do not have that build or its repository-supplied dependencies installed.

You can force building this with python setup.py build_ext --inplace

About that, no. That command doesn't work for me, don't think it ever did. The errors it produces are shown above. In the past it's been safe to just ignore those errors -- I had this noted in a small document I maintain for doing system installs and manual builds of various programs.

For the first error, this should be a easy fix. Looks like you missed importing modules via requirements.txt

Well, I didn't miss anything, for sure -- if a module is missing from requirements.txt that isn't on me 😉 That said, that module IS listed in that file and indeed it was installed automatically. See the above build log.

Answer 16 · 2024-08-05T10:26:57.000Z

Thanks for the update. I got a bit lost between all the issues and thought I better ask.
Regarding platformdirs, I mentioned this because your error log 8 h ago telling it is missing (ModuleNotFoundError in last line). It wasn't missing in requirement.txt because I changed the module from appdirs to platformdirs for pronterface v 2.1 (#1426) 😉

Anyway, this do not help you. I'll try to build a VM with your Linux version and try do install Pronterface from source. But this will take some time as I have a very slow line here and my Linux knowledge is very limited these days. Well, I will see what happen.
:)

Answer 17 · 2024-08-09T07:38:43.000Z

Hi @VanessaE,

I was able to install a VM with Debian 12.6 in the end and go thru all the quirks to get a usable Python environment with everything what is needed for Pronterface. Even the compiling the G-Code parser works fine after I managed all quirks with GCC and Python. But I'm not able to create a working wxPython version that supports the Debian version and Python 3.11. What a waste of time.

Sorry, I can't help on this as long as wxPython do not support matching packages for Debian 12.6

Answer 18 · 2024-08-10T09:30:46.000Z

Hi all, sorry I've been terribly busy AFK lately.

ModuleNotFoundError: No module named 'platformdirs'

I seem to remember you run Pronterface using system packages instead of a virtual environment. I guess you already tried but just in case, installing the Debian package python3-platformdirs might solve that error.

Run inside a venv as one is normally told to, and I still have the problem of a completely broken 3d view as described above.

When doing so, it also complains on the console about not finding Cython

That's weird, after migrating to pyproject.toml the local installation should be as simple as python -m pip install . and it should install Cython and create the gcoder extension all by itself. This one particularly I don't think is related to the usual suspects, pyglet/wxPython. There's something else going on there.

But I'm not able to create a working wxPython version that supports the Debian version and Python 3.11

Please try using one of the pre-built wheels meant for Ubuntu instead of the Debian ones. They'll probably work on Debian.

Answer 19 · 2024-08-10T11:03:37.000Z

I seem to remember you run Pronterface using system packages instead of a virtual environment.

You remember correctly, because of the broken 3d view when I try to run it from inside of the venv.

I guess you already tried but just in case, installing the Debian package python3-platformdirs might solve that error.

Ah HAH! That made it work, outside of the venv.

Meanwhile, here's a revised build and run log with the platformdirs package installed as directed:

Show log...

vanessa@rainbird:~$ cd RepRap/
vanessa@rainbird:~/RepRap$ cd /home/vanessa/RepRap/
vanessa@rainbird:~/RepRap$ rm -rf Printrun ~/.cache/pip/
vanessa@rainbird:~/RepRap$ git clone https://github.com/kliment/Printrun.git
Cloning into 'Printrun'...
remote: Enumerating objects: 13545, done.
remote: Counting objects: 100% (1065/1065), done.
remote: Compressing objects: 100% (439/439), done.
remote: Total 13545 (delta 647), reused 896 (delta 535), pack-reused 12480
Receiving objects: 100% (13545/13545), 81.41 MiB | 38.75 MiB/s, done.
Resolving deltas: 100% (8513/8513), done.
vanessa@rainbird:~/RepRap$ cd Printrun
vanessa@rainbird:~/RepRap/Printrun$ python3 -m venv venv
vanessa@rainbird:~/RepRap/Printrun$ source venv/bin/activate
(venv) vanessa@rainbird:~/RepRap/Printrun$ python3 -m pip install -r requirements.txt
Ignoring pillow: markers 'sys_platform == "win32"' don't match your environment
Ignoring pyobjc-framework-Cocoa: markers 'sys_platform == "darwin"' don't match your environment
Ignoring pyreadline3: markers 'sys_platform == "win32"' don't match your environment
Collecting pyserial>=3.0
  Downloading pyserial-3.5-py2.py3-none-any.whl (90 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 90.6/90.6 kB 1.2 MB/s eta 0:00:00
Collecting wxPython>=4.2.0
  Downloading wxPython-4.2.1.tar.gz (73.7 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 73.7/73.7 MB 32.5 MB/s eta 0:00:00
  Preparing metadata (setup.py) ... done
Collecting numpy>=1.8.2
  Downloading numpy-2.0.1-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (19.5 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 19.5/19.5 MB 52.4 MB/s eta 0:00:00
Collecting pyglet<2.0,>=1.1
  Downloading pyglet-1.5.29-py3-none-any.whl (1.1 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 1.1/1.1 MB 49.2 MB/s eta 0:00:00
Collecting psutil>=2.1
  Downloading psutil-6.0.0-cp36-abi3-manylinux_2_12_x86_64.manylinux2010_x86_64.manylinux_2_17_x86_64.manylinux2014_x86_64.whl (290 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 290.5/290.5 kB 33.4 MB/s eta 0:00:00
Collecting lxml>=2.9.1
  Downloading lxml-5.2.2-cp311-cp311-manylinux_2_28_x86_64.whl (5.0 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 5.0/5.0 MB 50.3 MB/s eta 0:00:00
Collecting platformdirs
  Downloading platformdirs-4.2.2-py3-none-any.whl (18 kB)
Collecting dbus-python>=1.2.0
  Downloading dbus-python-1.3.2.tar.gz (605 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 605.5/605.5 kB 42.6 MB/s eta 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Collecting pillow
  Downloading pillow-10.4.0-cp311-cp311-manylinux_2_28_x86_64.whl (4.5 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.5/4.5 MB 56.5 MB/s eta 0:00:00
Collecting six
  Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Building wheels for collected packages: dbus-python
  Building wheel for dbus-python (pyproject.toml) ... done
  Created wheel for dbus-python: filename=dbus_python-1.3.2-cp311-cp311-linux_x86_64.whl size=119821 sha256=c6b6fe7f12468659cf5bbd47537e6ba009b1e45758358db8b56f3541a111df4f
  Stored in directory: /home/vanessa/.cache/pip/wheels/84/33/c2/bb34ffd273446cb228d2154aa702365159f5a7dcc5278584ce
Successfully built dbus-python
Installing collected packages: pyserial, pyglet, six, psutil, platformdirs, pillow, numpy, lxml, dbus-python, wxPython
  DEPRECATION: wxPython is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559
  Running setup.py install for wxPython ... done
Successfully installed dbus-python-1.3.2 lxml-5.2.2 numpy-2.0.1 pillow-10.4.0 platformdirs-4.2.2 psutil-6.0.0 pyglet-1.5.29 pyserial-3.5 six-1.16.0 wxPython-4.2.1
(venv) vanessa@rainbird:~/RepRap/Printrun$ 


[switched to another terminal]


vanessa@rainbird:~$ cd ~/RepRap/Printrun/
vanessa@rainbird:~/RepRap/Printrun$ python3 pronterface.py --verbose --config ~/.config/Printrun/pronsolerc-2.x-small-HC 
WARNING:root:Memory-efficient GCoder implementation unavailable: cannot import name 'gcoder_line' from 'printrun' (/home/vanessa/RepRap/Printrun/printrun/__init__.py)
DEBUG:root:set last_window_maximized False
DEBUG:root:set last_window_width 1280
DEBUG:root:set last_window_height 720
DEBUG:root:set port /dev/Hypercube_small
DEBUG:root:set baudrate 250000
DEBUG:root:set build_dimensions 200.00x200.00x275.00+0.00+0.00+0.00+0.00+0.00+0.00
DEBUG:root:set extruders 1
DEBUG:root:set uimode Compact
DEBUG:root:set tempgauges True
DEBUG:root:set lockonstart True
DEBUG:root:set xy_feedrate 30000
DEBUG:root:set z_feedrate 6000
DEBUG:root:set e_feedrate 250
DEBUG:root:set antialias3dsamples 4
DEBUG:root:set trackcurrentlayer3d True
DEBUG:root:set gcview_path_height 0.2
DEBUG:root:set last_file_filter 0
DEBUG:root:set last_file_path /tmp
DEBUG:root:set recentfiles ["/tmp/Commodore Gaming case front vent panel.gcode", "/tmp/trash can lid patch 1.gcode", "/tmp/RAMLink enclosure - top.gcode", "/tmp/RAMLink enclosure - bottom.gcode", "/tmp/C128-DCR power tap mounts - reuse the VGA port's hole - bezel.gcode"]
DEBUG:root:set rpc_server False
DEBUG:root:set slicecommandpath /data/Archives/Software/Linux/SuperSlicer-ubuntu_18.04-2.5.59.0.AppImage
DEBUG:root:Unknown variable 'slicecommandpath'
DEBUG:root:set slicecommand
DEBUG:root:set sliceoptscommand
DEBUG:root:set display_progress_on_printer True
DEBUG:root:set viz3d True
DEBUG:root:set graph_color_background #FFFFFF
DEBUG:root:set last_bed_temperature 75.0
DEBUG:root:set last_temperature 235.0
DEBUG:root:button 0 "Purge 300 mm" /c "#0040c0" purge300
DEBUG:root:button 1 "Fan off" /c "#800000" M107
DEBUG:root:button 2 "Fan on" /c "#00ff00" M106 S255
DEBUG:root:set total_filament_used 3063228.55086376
DEBUG:root:set last_extrusion 100
DEBUG:root:macro purge200
DEBUG:root:  G28
DEBUG:root:  G1 X5 Y5 F12000
DEBUG:root:  G1 Z0.2
DEBUG:root:  G92 E0
DEBUG:root:  G1 E200 Z20 F30
DEBUG:root:  G1 Z275 F12000
DEBUG:root:macro purge300
DEBUG:root:  G28
DEBUG:root:  G1 X-3 Y-3 F12000
DEBUG:root:  G1 Z0.2
DEBUG:root:  G92 E0
DEBUG:root:  G1 E300 Z25 F30
DEBUG:root:  G1 Z275 F12000
DEBUG:root:button 3 "Park bed" /c "#ff8000" G1 Z277 F12000
DEBUG:root:macro load600
DEBUG:root:  G1 E600 F1800

EDIT: replaced that log with a new build that includes erasing and re-cloning Printrun and wiping my pip cache and running the new build with my usual config file.

I did not try to USE the first build that I did in a temp dir, that was just a quick compile and run to see if it looks right, and it does. Since it seems right, and it's able to at least connect to my printer, I've replaced my working install with a whole new build (not done in the temp dir of course 😛 ). I will report back if it has any problems.

Still has that damn autoraise thing happening tho.

Please try using one of the pre-built wheels meant for Ubuntu instead of the Debian ones. They'll probably work on Debian.

I tried that previously, no bueno. One of the Ubuntu wheels did "work", but it didn't behave any better than just letting it compile WxP. But that was before you mentioned the right package to install for the platformdirs issue.

Answer 20 · 2024-08-11T14:59:39.000Z

Hi @rockstorm101,

Please try using one of the pre-built wheels meant for Ubuntu instead of the Debian ones. They'll probably work on Debian.

I tried that as well with https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-22.04/wxPython-4.2.1-cp311-cp311-linux_x86_64.whl and got a lot of errors with not available wxPython and missing library imports for all kind of lib* when I try to use it with Ppronterface.

I don't know if his a a problem with the Debian-12.6.0-amd64-netinst.iso I had install in a newly created VM. I tried to add a bunch of those missing modules but that never seems to end 🙂
I've download now an other Debian DVD version and will test if that will work any better or is at least more complete. I always have the feeling that all the time something is missing and bite me in the back.
Or maybe Debian and me are simply not a good combination 😇

Answer 21 · 2024-10-05T10:04:47.000Z

I will report back if it has any problems.

Hi @VanessaE, since you didn't report back, may we assume everything is running smooth for you so far? That would mean the "only" remaining issue would be the broken 3D view.

Answer 22 · 2024-10-05T10:07:15.000Z

Oh, yes, sorry about that. The program runs pretty much as it did before when I realized back then I had been running it outside the venv (i.e. it's only broken when inside it).