Python: Bump minimal python version to 3.10 #56499
Conversation
lbartoletti
added
Build/Install
Debian bookworm has Python 3.11, so this not an issue for backports. |
|
Ok for Fedora, F38 (oldest non EOL release) has python-3.11. |
|
OpenBSD 7.4 ships 3.10 by default (and that since openbsd/ports@80fda491b 1.5 years ago), and we'll probably switch to 3.11 someday in the future. Fine with me either :) |
|
How is it on macOS? |
|
FreeBSD has possible versions 3.8, 3.9, 3.10 and 3.11, default version is 3.9 until know. |
Thanks! and python 3.11 by default soon 😉 |
you know who we have to ping? @chenrui333 You seem to be the brew maintainer, but maybe you're not the one in charge of compilation? |
|
Debian bullseye is still at Python 3.9. |
OK, but. Is it a problem? Since, if I'm not wrong, the QGIS version will be blocked with the current dependencies of this system. It seems to me, as @sebastic says, that we'll only be on bookworm. |
QGIS 3.36 is currently available for bullseye https://qgis.org/en/site/forusers/alldownloads.html#repositories. |
The Py 3.10+ requirement would be for 3.38 only, with 3.36 being the last one packaged for Bullseye |
|
If I'm not wrong, it's also OK for Conda and VCPKG ( cc @SrNetoChan @m-kuhn ) ? So, for now, the only one that remains to be bumped is for OSGEO4W, right? |
@lbartoletti conda-forge is currently building QGIS for 3.9, 3.10, 3.11 and 3.12. So I think it's ok to drop Python 3.9 build. I guess conda-forge will also stop building other packages for 3.9 at some point. |
Humm, macOS 😃? As far as I can see, it is at 3.9.6 (from xcode?) on Sonoma and my QGIS version is built with 3.9.5. But I can't provide more details, and no idea who is now behind the scene on QGIS side. |
|
So, we have 98% of our users who can't yet migrate, or we don't have the information, and the remaining 2% have already answered that it's okay via the 9 contributors to this review. Beautiful! 🤣 |
|
I assume it's not easy to provide that on mac with the current stack with macdeps. bumping the python ecosystem will be a lot of work. There is a POC installer based on conda which already ships a newer python version, but I don't feel like supporting that in the long run. There are some experiments I do now and then with vcpkg that should result in an installer but it's done in spare time only (mostly) at the moment, as funds are scarce for that. |
Required by qgis/QGIS#56499 Fixes qgis/QGIS#54491
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
github-actions
bot
added
the
stale
|
@lbartoletti merge and run away ! ;) |
github-actions
bot
removed
the
stale
+1 😂 |
|
I'm writing from two perspectives: packager, and maintainer of other things. I maintain the qgis package in pkgsrc, a multi-OS multi-OS-version multi-CPU source-based packaging system that has quarterly releases. It's not "bleeding edge", in that package maintainers update to releases recommended by upstream, and we have accomodations for unstable things like python by having multiple versions. But, we have zero "LTS". pkgsrc currently has python 2.7, 3.8, 3.9, 3.10, 3.11 and 3.12. The default value is 3.11. We mark each package with the versions of python it supports. qgis (3.28.15) is currently marked as incompatible with 2.7 and 3.8; that might be off. I will soon update to 3.34.x; it's only recently been recommended and I haven't gotten to it yet. That's a long way of saying that if newer qgis needs 3.10, we will hardly notice, and it's just a matter of adding 3.9 to the not-ok list. (Having all these versions is a clue that python is not really stable; you can't just install 3.12 and have everything work, and pretty much all programs in python have to release new versions with changes for each python minor version.) From maintaining other Free Software, I am very cranky about the expectations of people running LTS systems, especially those systems that have license fees and companies behind them, and about people using LTS in a non-personal environment. LTS is an intentional choice to run old software. But people want it both ways, to run old software and to run new software. As long as they do the work, that's their call. But often they expect Free Software projects to do extra work to accomodate LTS, while the LTS companies and the companies choosing to have LTS on their systems do not contribute meaningfully to those support costs. As far as I'm concerned, if people want to run software from 2019, they can - and that means qgis from 2019 with their 2019 python. And if they want to pay a consultant to arrange for 2024 qgis on their 2019 systems, that's fine too. If Red Hat wants to fund a maintainer to accomodate LTS (and other things, because there will be time from other people too), that seems ok. But it's not ok to expect the qgis project to accomodate this. I see this as not about mac; macOS that is one version old on a 2017 computer (crazy that a 7 year old computer isn't supported by the latest, but that's Apple pretending to be environmentally conscious) has python 3.11. Also, people on LTS who want new qgis can build python, build all the prereqs, and build qgis. They can even do this by installing pkgsrc on GNU/Linux. The other question is what is gained by increasing the version. I don't know if
Overall I think it's a low bar to decide to stop qgis trunk working with old python (any of the above counts), and a policy of "qgis trunk desupports a python 3.x when it becomes EOL" seems very reasonable. So I'm +1 to merge, unless RH or Ubuntu would like to pay all costs of continued support. So far we don't seem to have heard from them that they are willing, unless I'm missing something. |
|
The current packages are still built using macdeps, which is no longer maintained and an update does not seem reasonable. |
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
github-actions
bot
added
the
stale
lbartoletti
removed
the
stale
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
github-actions
bot
added
the
stale
lbartoletti
removed
the
stale
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
github-actions
bot
added
the
stale
|
While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist. |
github-actions
bot
removed
the
stale
|
@lbartoletti I don't think there's any way we can progress this until the mac situation is resolved |
|
Side question, but would it be possible to first bump to Python version 3.9 first for QGIS 3.40, which will be the next LTR ? This PR would still be welcome of course for 3.10 It would help a lot PyQGIS developpers :) |
|
From the pkgsrc viewpoint, we don't actually care what the minimum is; we are now using 3.12 by default as of a few weeks ago, up from 3.11. But, we also just dropped 3.8 and 3.9 from the set of versions for which we build by default, for a package that is python. 3.8 is ancient, but very recently (a few months) the number of upstreams that are failing to build with 3.9 has been increasing a lot. As for mac, building 3.11 or 3.12 on a mac works fine. I think the real issue then is that mac packaging of qgis, which already requires building a lot of things, just has to build python too. macOS is basically a kind of troubled LTS release. |
|
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
github-actions
bot
added
the
stale
|
While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist. |
|
Once #60039 is merged, the min python version can be increased to 3.10 if I'm not mistaken |
github-actions
bot
removed
the
stale
🪟 Windows buildsDownload Windows builds of this PR for testing. |
🪟 Windows Qt6 buildsDownload Windows Qt6 builds of this PR for testing. |
|
@nyalldawson after #60039 it will no longer be possible to create builds with the legacy mac packager dependencies. In discussions with the PSC there was a preference to invest into qt6 based builds with notarization rather than keeping qt5 builds (which would also be possible with vcpkg), so as a result this indeed means stopping to deliver qt5 builds with the 3.40 release line being the latest to ship mac builds with qt5. |
Ok, sounds reasonable to me! 👍 |
Description
Our minimum required Python version has been end-of-life since 2023-06-27. Most major distributions have long since moved to Python 3.9 or higher.
Following the discussions on the ticket, I propose to set the minimum version directly to 3.10. Most bleeding edge/rolling release distributions already have multiple versions of Python or a minimum version higher than 3.9.
While I doubt this will be merged directly — and I don't insist on it — I would like to discuss it in the PR. Developers, before merging, I want to hear from system packagers, who are directly affected by this; before users and plugin developers.
cc @jef-n @manisandro @rhurlin @landryb @gdt @sebastic @chenrui333
Fixes #54491