Python: Permit installation on Python 3.8

[amotl]

About

Even if EOL, some projects still provide support for Python 3.8.

NB: Please rebase and merge only after integrating GH-174, to validate the patch does not break CI.

References

• Bump cratedb-sqlparse from 0.0.13 to 0.0.14 cratedb-toolkit#412

[surister]

Which projects that have python version 3.8 might use cratedb-sqlparse?

[amotl]

In this case it is CrateDB Toolkit that is still validated against Python 3.8, because it doesn't cause much harm.

• Bump cratedb-sqlparse from 0.0.13 to 0.0.14 cratedb-toolkit#412

[surister]

In this case it is CrateDB Toolkit that is still validated against Python 3.8, because it doesn't cause much harm.

* [Bump cratedb-sqlparse from 0.0.13 to 0.0.14 cratedb-toolkit#412](https://github.com/crate/cratedb-toolkit/pull/412)

Wouldn't it make more sense to make cratedb-toolkit's minimun 3.9? I think upgrading away from EOL versions is a good practice otherwise what is the argument of not also supporting 3.6 and 3.7 for example

[amotl]

Wouldn't it make more sense to make cratedb-toolkit's minimun 3.9?

As long as it doesn't hurt to support older versions, I don't see a reason.

I think upgrading away from EOL versions is a good practice otherwise what is the argument of not also supporting 3.6 and 3.7 for example.

I absolutely agree, but also would like to extend and discriminate: It is always advisable to upgrade away from EOL versions when using software. However, this is does not correlate to supporting EOL software as a software distributor or vendor at all, for people who need it.

Supporting Python 3.6 and 3.7 is painful in certain conditions, that's why this is out of scope, otherwise it would be similar, right. A few other pieces from our pen still bear 3.6/3.7 support where easily possible. ¹²³

Footnotes

1. https://pypi.org/project/crate/ ↩

2. https://pypi.org/project/grafana-client/ ↩

3. https://pypi.org/project/pytest-mqtt/ ↩

[surister]

As long as it doesn't hurt to support older versions, I don't see a reason.

I can think of some: Security concerns, supporting EOL versions disincentivize the user to update and move away from Python versions that are not updated anymore, which is the opposite of today's software common practice also more maintenance cost and overhead.

However, this is does not correlate to supporting EOL software as a software distributor or vendor at all, for people who need it.

Why not? It is actually the vendor's practice of releasing often and having the user upgrade versions what produces the first.

for people who need it.

Which is probably no one? Do we know any users in 3.8? Even if we do, they should update, even crate's dependencies orjson and urllib recently moved away from 3.8, so any 3.8 user will stop getting bug and security patches, why should we promote staleness?

Another question is, if everybody is doing it, why aren't we?

[surister]

Maybe @kneth or @bmunkholm need to pitch in, as this speaks to a broader organizational topic that can have an impact to the very company evaluation and security practices adherence.

What is the strategy when it comes to supporting software versions, do we perpetually support unsupported language versions, if so until when? or we just move away from EOL and keep updating our software at a steady pace. We should have a clear, coherent and agreed upon strategy, let's not make decisions on personal preference.

[amotl]

Hi. I think it's not such a big deal to support such versions.

for people who need it.

Which is probably no one? Do we know any users in 3.8? Even if we do, they should update [...]

Yeah, that's the point of supporting older versions: For the mostly unknown participants of software consumers who just can't update. If it would be the free choice of everyone to update, it wouldn't be a big deal at all, and I wouldn't even start a discussion about it, because everyone should be encouraged to update, always.

The whole story is really just about permitting the installation, and absolutely doesn't contradict any of the best practises you are enumerating.

[surister]

Hi. I think it's not such a big deal to support such versions.

I think it is, as I stated several reasons and concerns in the previous comments.

Yeah, that's the point of supporting older versions: For the mostly unknown participants of software consumers who just can't update

But this decision does not stem from a coherent and cohesive organizational strategy, and certainly not an agreed upon, otherwise why stop at 3.8, we can support down to 3.1, what's the rationale of only doing 3.8, after all, I'm sure there are people who can upgrade from 3.6 because of their environment concerns.

and absolutely doesn't contradict any of the best practises you are enumerating.

I think it does contradict supply chains best practices.

I think at this point we are just repeating arguments and will not agree, which is fine. I want to reiterate that I think we should take this decisions as a team/organization, so let's wait for others to pitch in.

[kneth]

Alternatively we could test against 3.8 but remove the version from pyproject.toml. As I am not a Python person, I have no strong oppinion.

[amotl]

When not using requires-python = ">=3.8" in pyproject.toml, the permission to install it on Python 3.8 will not be given.

[amotl]

why stop at 3.8, we can support down to 3.1, what's the rationale of only doing 3.8, after all

There is no reason for that, other than obstacles that it causes tremendous efforts to support such old versions, like CI runners becoming unavailable, and new code features being used which are not compatible with older versions, and so on.

[bmunkholm]

I'm not aware that we have a guideline or strategy for this.
But I think that if we were to make one, it would likely be along the lines of not supporting EOL versions. Otherwise it's hard to draw the line and it becomes something that we would have to judge/discuss for each piece of software and versions of dependent software. How would we even describe that guideline? Simplicity of the guideline, clear guideline, security, best practices, reduced discussion and maintenance costs etc seems to all speak to not supporting EOL versions.

After all, if there is a very specific niche need for an old version, people are free to use our newest version that supports that old version (with the same downsides: no new fixes or features) or fork our software. Or they could request us to support it. I doubt we will ever get such a request. Should that assumption be wrong, we could bring this up again.

Bottom line: If you ask me we should not support EOL versions.

[kneth]

If you ask me we should not support EOL versions

I tend to agree here. If a customer comes with a specific version request, we can either explain why an upgrade is needed or estimate what it costs to support an EOL version.