generate_packets.py minimum Python version
alienvalkyrie Reply To alienvalkyrie
Given the use of a python3 executable, our minimum supported version is in the Python 3 range
Actually, you can still do '/usr/bin/python generate_packets.py' on a system with python2, and it works. But do we want to be semantically correct here, or would it be better to tell people that they should not use long EOL python2?
alienvalkyrie Reply To cazfi
Reply To alienvalkyrie
Given the use of a python3 executable, our minimum supported version is in the Python 3 range
Actually, you can still do '/usr/bin/python generate_packets.py' on a system with python2, and it works. But do we want to be semantically correct here, or would it be better to tell people that they should not use long EOL python2?
I was referring more to the fact that the build system only looks for python3 – working with Python 2 instead is possible, of course, but without python3, autogen.sh will fail, so anyone working with Python 2 will already need more extensive workarounds (or build everything manually).
But yeah, I'd go the route of saying "this might work with a lower version, but we're only officially supporting <whatever> and higher". Having a more recent minimum supported version would also allow modernizing (and pythonicizing) the script with newer language features and useful library functions.
alienvalkyrie Some upper bounds for the minimum supported version (based on what runs on / comes with common operating systems):
So our range of possible minimum supported versions is somewhere between 3.0 and 3.4. I'd gravitate toward going with Python 3.4 (plenty of features that might turn out to be useful; particularly pathlib might be relevant to our use case).
Reply To alienvalkyrie
without python3, autogen.sh will fail
Good reminder about autogen.sh. Whatever gets decided as the minimum python version, autogen.sh check should be updated to require.
On macOS, Apple has reliably bundled only Python 2.7 with the last several versions of macOS. This is obviously an old version and no longer supported. The word on the MacPorts lists1 is that Apple will stop supplying Python with macOS 12.3, which is currently in beta test.
The Apple stance on Python (and other scripting languages) is that you should not count on Apple to supply any version, you should install the runtime you require with your app.
I am working on delivery Freeciv to macOS via the MacPorts distro. It can install both the GNU autotools, and any necessary version of Python. So, the MacPorts distro of Freeciv should not be inconvenienced by Apple withdrawing Python 2.7 from macOS. Theoretically. I hope.
1 https://lists.macports.org/pipermail/macports-dev/2022-February/044121.html 2 https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes/ , search for "Scripting Language Runtimes"
Reply To jdlh
I am working on delivery Freeciv to macOS via the MacPorts distro.
This might not be an issue for you. We need python only when building from the git checkout. In the release tarballs the python generated files are already present (and up to date). Just be sure not to use ./autogen.sh (which you don't need as 'configure' and other files are already generated for you), but ./configure.
Obviously this is an issue for anybody wanting to do such development on macOS that would require recreating those python generated files.
alienvalkyrie alienvalkyrie Alright, so the way I understand it – the relevant OS/distros mentioned here either come with Python 3.4 or newer, or can install it just as easily as the other needed build tools (or other versions of Python 3, for that matter). The same is not true for 3.5 nor 3.6 unless we choose not to support building on Ubuntu 14.04 LTS and Debian 9 LTS, respectively, without additional hassle.
So choosing 3.4 as our minimum Python version for now (and at least until April 2024) seems like the sensible thing to do – unless we drop support for aforementioned LTS versions, in which case we could bump that up to Python 3.6.
There is an argument to be had about if it's a good idea to also increase the minimum supported version for S3_0, or if we should just fix the generate_packets.py comment there – in case someone's building the new stable release on another system where they can only get even older versions of Python 3. I think it's unlikely to matter, but something still rubs me wrong about the idea of changing the dependencies in the middle of the 3.0.x series.
Reply To alienvalkyrie
wrong about the idea of changing the dependencies in the middle of the 3.0.x series.
Please don't increase dependencies on already released branch - people who already using it must be able to also update within the series. Consider this a security issue - the update might be a fix to a vulnerability.
alienvalkyrie alienvalkyrie Reply To cazfi
Consider this a security issue - the update might be a fix to a vulnerability.
Good call; that's the point I figured must exist, but couldn't quite put my finger on.
S3_0 patch that just changes the comment is attached.
List the change in the minimum version in the README.packaging of the branch where it first happens.
alienvalkyrie alienvalkyrie alienvalkyrie alienvalkyrie Reply To cazfi
List the change in the minimum version in the README.packaging of the branch where it first happens.
Done.
alienvalkyrie alienvalkyrie alienvalkyrie 
The comment in common/generate_packets.py claims it's compatible with every Python version since 1.5, and says to keep it that way; in particular, not to replace string.join calls. The update to make the script Python-3-compatible did just that.
Clearly, the script is not 1.5-compatible anymore (nor does it need to). Given the use of a python3 executable, our minimum supported version is in the Python 3 range – we should figure out / decide what specific version we want that to be, and update the comment accordingly.