alienvalkyrie Reply To cazfi
As for freeciv-3.2, the trusty testing environment is already very limited .... It wouldn't be a problem to drop "active" testing from that one
It looks like Ubuntu Trusty has a python3.5 package (universe, not main), so with appropriate build tool support (i.e. figuring out which of python3 and python3.5 works), it might even still be possible to build from git on Trusty without significant additional hassle, if minimum version is bumped to 3.5.
As for whether we should bump the minimum Python version requirement, you know you won't find me saying "no" to that any time soon; the upgrades to Python 3.5 and especially 3.6 are incredibly useful (perhaps useful enough to justify no longer supporting older environments). And it sounds like there's not much standing in the way of upgrading to Python 3.5; either some build tool configuration work, or dropping an environment that already only allows the minimum (and will be EOL anyway before freeciv-3.2 gets released). Upgrading to Python 3.6 for freeciv-3.3 shouldn't even be a problem either, given that both xenial and stretch will be EOL by the time S3_3 is likely to approach d3f anyway (going by the two-years-per-version release cycle). (If we do the whole "looking for alternate python executables" thing, even Python 3.7 could be fine; Debian Buster offers that natively and Ubuntu Bionic has a universe package for it.)
Reply To cazfi
I'd suggest that we adopt a policy that autotools build python requirement follows meson build minimum requirement
If meson is going to become the preferred/primary build tool, then python-follows-meson sounds like a sensible plan; though people who might be working on a system that supports autotools, but not meson, might be indirectly affected by a meson update that also changes the minimum Python version. I don't know if that's a realistic thing to be worried about.
Reply To alienvalkyrie
As for whether we should bump the minimum Python version requirement, you know you won't find me saying "no" to that any time soon
I sort of assume that we can even find a volunteer to do that change...
alienvalkyrie alienvalkyrie Reply To cazfi
Reply To alienvalkyrie
As for whether we should bump the minimum Python version requirement, you know you won't find me saying "no" to that any time soon
I sort of assume that we can even find a volunteer to do that change...
We can. Attached patch has a textual dependency on #43945.
This patch does not yet mention the future python-follows-meson policy – I figure we'll cross that bridge when we get there, i.e. after S3_2 branching.
It also does not attempt looking for an alternate python3.5 executable – doing so would likely have to happen in configure rather than autogen.sh anyway, which would complicate building from tarball without Python.
Reply To alienvalkyrie
This patch does not yet mention the future python-follows-meson policy – I figure we'll cross that bridge when we get there, i.e. after S3_2 branching.
In case you want to open a ticket for that already, I created the "3.3.0" milestone (I thought we already had one, but we did not)
alienvalkyrie Reply To alienvalkyrie
It also does not attempt looking for an alternate python3.5 executable – doing so would likely have to happen in configure rather than autogen.sh anyway, which would complicate building from tarball without Python.
~> #44766
Reply To cazfi
Reply To alienvalkyrie
This patch does not yet mention the future python-follows-meson policy – I figure we'll cross that bridge when we get there, i.e. after S3_2 branching.
In case you want to open a ticket for that already, I created the "3.3.0" milestone (I thought we already had one, but we did not)
~> #44767
I was actually about to open that ticket anyway (and then bring up creating the milestone), but it seems great minds think alike :D
alienvalkyrie 
Let's split the discussion about possible bump of our minimum python version (for autotools builds) from #44615.
- Our current python requirement in master is 3.4.
- The oldest environment I still have in active testing (ubuntu trusty) has python-3.4.3
- The second oldest environments in active testing (ubuntu xenial and debian stretch) have python-3.5.2 and python-3.5.3, respectively
- Meson (0.57.0) build has minimum python requirement of 3.6
- Autotools build does not need python when building from a tarball
As for freeciv-3.2, the trusty testing environment is already very limited (the only supported client is sdl2, and even that does not have audio). It wouldn't be a problem to drop "active" testing from that one, and only do occasional builds by first preparing a tarball in a more modern environment. I'd want to keep support for building from the git repo for xenial and stretch.
-> Maybe we should bump minimum python requirement to 3.5 in freeciv-3.2?
As for freeciv-3.3 (-> master as soon as S3_2 has been branched), I'd suggest that we adopt a policy that autotools build python requirement follows meson build minimum requirement (i.e. requirement of the meson itself), as long as build from the tarball does not require python (so that older systems can still use tarballs prepared in newer environment)