Thanks for the explanation! That makes sense. So is it fair to assume that OctoPrint is developed/tested in an environment with pip version 19.0.1, and using any other versions of pip would be 'at your own risk'? If so I might downgrade my pip to match so I'm less likely to encounter things like this again. Not sure why I updated pip in the first place honestly (probably just assumed newer == better).
./pip -V
pip 22.2.2 from /home/pi/oprint/lib/python3.7/site-packages/pip (python 3.7)
pi@octopi-p1:~/oprint/bin$ ./pip install -U pip
Looking in indexes: Simple index, piwheels - Simple index
Collecting pip
Downloading pip-22.2.2-py3-none-any.whl (2.0 MB)
|████████████████████████████████| 2.0 MB 1.6 MB/s
Installing collected packages: pip
Attempting uninstall: pip
Found existing installation: pip 20.2.3
Uninstalling pip-20.2.3:
Successfully uninstalled pip-20.2.3
Successfully installed pip-22.2.2
pi@octopi-p1:~/oprint/bin$ ./pip install typing-extensions==4.3.0
Looking in indexes: Simple index, piwheels - Simple index
Collecting typing-extensions==4.3.0
Downloading https://www.piwheels.org/simple/typing-extensions/typing_extensions-4.3.0-py3-none-any.whl (25 kB)
Installing collected packages: typing-extensions
Attempting uninstall: typing-extensions
Found existing installation: typing-extensions 3.7.4.3
Uninstalling typing-extensions-3.7.4.3:
Successfully uninstalled typing-extensions-3.7.4.3
Successfully installed typing-extensions-4.3.0
1 Like
I can't speak for Charlie or Gina, but personally when I'm developing for OctoPrint core or my plugins I tend to have pip updated. We did have a problem with one of the early 20 something versions when they added the color output support IIRC that actually broke stuff pretty bad and took a couple of versions to get resolved.
Just to chime in here, I personally develop against Python 3.7 (to not accidentally use newer language features sigh), but keep pip updated as well to get an early warning of new breakage. The quoted pip version number is a minimum requirement that matches what is found on stock OctoPi 0.16, and probably should be updated soon because 0.16 can't even be updated to Python 3 anymore, at least not easily. But that doesn't mean OctoPrint is only guaranteed to work against that pip version, that means anything before that isn't tested.
During my release testing, I test updating against various OctoPi versions (currently Python 3 converted 0.17, 0.18 stock, up to date 0.18, 1.0.0 rc) and OctoPrint versions (stock on the OctoPi version + latest on relevant release channels), as well as a fresh install from pypi und Windows (fresh venv too, install from sdist and wheel) and Linux/OctoPi (replacement of stock install in situ prior to running wizard, install from pypi).
As mentioned elsewhere (and what a beautiful unintentional pun, @Charlie_Powell), OctoPrint's updating boils down to running pip install OctoPrint==<target_version> (though it actually uses an download URL for the release package on GitHub to allow for release channels to function, but that is the same code that ends up on PyPi). So, dependency resolving, updates of third party libs and pulling in new deps is all down to pip. And for some reason, for some of you here that is not properly working for the typing-extensions package, which is a dependency of a dependency of OctoPrint and nothing I even had on my radar let alone saw misbehaving.
I could add a version pin for that to OctoPrint's own dependencies, but frankly I'd like to avoid that as it could cause other issues down the road when whatever requires this dependency sees updates. So I'd rather prefer we figure out here why this is misbehaving (pip bug sounds quite likely actually) and rather solve it without a version pin.
Thanks for the information! Would it make sense to have a 'recommended' version (or versions) of pip for use with OctoPrint? For example you could (automatically?) capture the pip versions installed when you do upgrade testing, and then before a user upgrades OctoPrint there could be a check to see if the currently-installed version of pip is one of those known-good versions. If the user's pip version isn't on the list then you could show a warning and a suggestion to use one of the tested versions before upgrading OctoPrint.
I understand you've got to support a lot of different scenarios already, and I'm certainly not an expert in python so I don't know if this is a good idea. Just wondering if there's anything that could reasonably be done to keep stuff like this from happening again in the future - sounds like there have been 'broken' verisons of pip released before this too, so it may happen again and break people who've updated their pip at some point. It seems that if some testing is already being done that confirms that some pip versions are good, that information could be leveraged when deploying updates in the field.
Using Cura 5.1, linked to OctoPrint I seen the same, similar message; I think waiting a bit cleared it;
But Plugins greyed out; So moving back to previous version of OctoPrint that works without these issues
Where's the bug report? Otherwise this cannot be fixed, I cannot reproduce this.
Temporary Glitch; Seems to be OK with Plugins now:
Cura 5.1 shows Server issue for about 45 seconds then clears; log-on time to sever I think
I had a similar issue on the most recent upgrade and only got the time to look into it now. Updating pip fixed the issue. I saw there was a request for the existing pip version, fortunatley the update process warned me I was previously running 20.2.4 (on OctoPi 0.18.0 and OctoPrint 1.8.4). I don't think I explicitly updated this in the past as the Pi is dedicated to Octoprint, but I may have done an apt update (or possibly apt full-upgrade) at some point as maitenance.
I have no idea if it's related, but the Picam stopped working days before the update (the whole rig has been stable for a long time so two back-to-back issues are intriguing).
Best of luck
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.