Ha! You're much kinder that I would have been. If THEY'RE not even supporting it anymore, I would have long since pulled support!
5 Likes
This does make sense. No need to waste resources on something obsolete.
3 Likes
I am probably going to get blown up for this:
How do I go about this OctoPrint needing Python conversion?
Main post with all the explanation is here:
Edit: has now been added to the original post
2 Likes
Thank you. I poked around before asking, but wasn't sure what I was looking for.
1 Like
I am not a python developer, so I don't know how things like this are typically done in Python, but you should consider using SemVer. Basically, dropping support for Python 2 would be considered a breaking change, and thus you should increase the "major" version number (2.x.x). That you had other plans for what would be included in 2.x.x is immaterial. You version based on the changes you've made, not based on what gives you the warm-fuzzies.
1 Like
It's not breaking if python2 users are not provided the opportunity to upgrade. Python2 users will simply sit in limbo on 1.7.3 forever until they decide to upgrade their python environment or reflash OctoPi with a newer version.
1 Like
Since it's not guaranteed to know by version (ex. 0.18 dev version), is there a way to check to see which version of Python is running? I see these mentioned in my System Info...
env.python.pip : 20.3.3
env.python.version : 3.7.3
env.python.virtualenv : true
That`s one way to check it, the versions are also displayed in the lower left corner.
You will also see a notification if you're still running Python 2.
1 Like
We really don't need anyone lecturing @foosel on how to versioning her software.
Why do you think this is the right way to approach someone with your views on this topic?
5 Likes
I've stuck to semver for all of OctoPrint's development so far, which was often very very painful. Given how often I've had to do hotfix releases or new RC rounds because the one or other dependency broke even on patch version increases, I'm at a point where I won't make my life even more difficult for pure semantics that frankly nobody besides a small handful of people even seem to remotely care about in this particular case which strictly speaking also doesn't even classify as the "breaking API change" that would mandate a major version increases following semver - the API stays as is, it's the required runtime environment that changes.
1.8.0 will have all the necessary flags set to not install under python 3 (instead of installing but then breaking, and I spent several hours just yesterday to ensure exactly this), people on python 2 will be redirected to a working and heavily pinned legacy version that should hopefully just continue to work for them for a while to come. I'll continue to stick to semver for development related changes (think internal footprints and other changes in the documented API that plugin and third party client developers work against), but I'm drawing the line here for once given that I've taken all kinds of precautions to prevent breaking changes from actually taking place for people (something that cannot be said to most projects out there) and given that I will have to introduce actual breaking changes in 2.0 it would otherwise just cause a total disruption that would cause me a TON of communication overhead.
Development philosophy is nice and well, but in reality you sometimes you just have to be pragmatic instead of sticking to lofty principles and confusing people in the process more than helping them.
5 Likes
Glad to know you're aware of SemVer and considered it. That's all I wanted to accomplish. 
I disagree with your conclusion, but that's ok. I still love OctoPrint (It's amazing!) and will continue to use it, and I'm not at all upset with you or anyone here. I don't know why a few people seem to have been upset my my comment. 
To give but one example, when projects in the Node.js ecosystem drop support for an old version of Node, most consider that a breaking change, because it is not safe to blindly upgrade. Of course no software is perfect, but my interpretation of the SemVer rules is that as long as the major version hasn't changed, I should be able to accept any minor/patch upgrades without any danger to my project breaking, because the version number indicates that only feature-additions and/or bug fixes were made. If I happen to be running on an old version of Node (or Python) and upgrading to a new minor version of the library/app broke things, that would be a violation of (my interpretation of) SemVer.
Anyway, thanks again for a great project, and keep up the great work. 
1 Like
As I said, you won't be able to update to a new version that is Py3 exclusive. Pip simply won't let you. So you won't be able to "accidentally" update and then find stuff broken, you simply won't be able to update in the first place, and I will also put stuff in place so you won't even get told there's a new version available.
This might not be standard in the Node (or sadly the Python community, as I found), but it certainly is something I intend to make every use of that I can.
Your phrasing made you sound very much like you were lecturing me on something that people know I'm well aware of, have been sticking to, even explained repeatedly in public communication on how I've been bending over backwards to ensure nothing breaks for people, and in which I have probably been doing a better job than most projects in adhering to way beyond what SemVer actually requires (which, again, is on public API changes, not runtime environments - this is your interpretation and/or desire, but the SemVer spec clearly only speaks about publicly consumed APIs of any kind). And that kind of rubbed people the wrong way, including myself tbh.
In either case, rest assured that I've put a TON of thought into this over the course of the past two years, took precautions and will do everything in my power so that most people who would in theory be affected probably won't even notice something's changed, unless being told so (which OctoPrint will do however to ensure they are aware that action on their part will be needed to continue to receive upgrades). And please also keep in mind that OctoPrint isn't a library, it's an end user facing application - the users aren't projects, build automations, package.lock files or whatever else, it's people running it on actual hardware.
edit Also, just for the record, the docs on OctoPrint's versioning scheme 
I apologize.
I misunderstood the python particulars of the problem, and I was also looking at it through the lens of a library which needs a different kind of version numbering contract than a product.
I never meant to cause any problems or hurt feelings. I do love OctoPrint, but I have never before stuck my head into the development side of it. Never felt the need. I'm not aware of any of what's common knowledge in the community, and never had the need to read the docs because it's such a great, easy to use app! My intent was only to share knowledge if it happened to be missing (which based on my incorrect interpretation of how semver would apply, it did seem to maybe be missing).
I sent you a donation as a gesture of my goodwill. Thanks again for such a great project.
5 Likes
All good, no hard feelings here and I'm glad we could get this misunderstanding out of the way
1 Like
Will I need to remove older versions of python? I’ve been getting weird update issues already from this issue with plugins.
No, OctoPrint is only concerned with the version of Python it's installed under - the others should not get in the way. I'm not aware of any issues with plugins getting confused like this - if you open your own get help topic we should be able to look into it.
1 Like