Drop support for end-of-life Python 3.6

[hartwork]

https://endoflife.date/python

[HorlogeSkynet]

Hey again @hartwork ! Do you think dropping Python 3.6 (indeed EOL) would help us drastically reduce technical debt for this project ?
What I have in mind is the Ansible's core team reaction when we dropped Python 3.5 lately... I fear dropping 3.6 may bother many developers vendoring distro in their package.
Tell me what you think about this !

PS : I also note maintaining multiple branches requires additional work (and time !) and we often forget about it.

[hartwork]

@HorlogeSkynet I see, I did not have those branches and Ansible on the radar. To be frank, I think it makes zero sense to put volunteer time (or even anyone's time) into maintaining end-of-life Python support — branches or not — just because some enterprises do not manage to update their stack beyond state of a museum — that's on them. If that's the constraint bubble we're in here, I'll probably be out after we finished PR #328 together.

[HorlogeSkynet]

To be frank, I think it makes zero sense to put volunteer time (or even anyone's time) into maintaining end-of-life Python support — branches or not — just because some enterprises do not manage to update their stack beyond state of a museum — that's on them.

I completely agree.

If that's the constraint bubble we're in here [...]

I didn't intend to put their burden onto ourselves, I just meant that (IMHO) Python 3.6 currently doesn't constrain distro code base.
To put it another way, of course that I would have welcomed 3.6 drop if a bug, a new feature and/or one of our dependencies force us to do it (for instance, as done in #281 to allow type hints introduction).

[...] I'll probably be out after we finished PR #328 together.

😢 the world needs you here too Sebastian

[hartwork]

@HorlogeSkynet from what I can see in the code base, you're right, the only practical burden from 3.6 support today is wasted CI runtime.

[HorlogeSkynet]

"Usually" I disable intermediate Python versions in the jobs matrix to "spare" some CI time (and energy). With upstream Python versioning and its standard library, if CI passes 3.6 and 3.9, I assume it would pass 3.7 and 3.8 too 🤷

[hartwork]

@HorlogeSkynet fully agree, but (for myself) I decided to not suggest dropping intermediate versions here because of things like

distro/src/distro/distro.py

Line 628 in 6d44662

# Python < 3.8

and

distro/src/distro/distro.py

Line 55 in bab1b9a

# Python 3.7

. It would need a closer look and felt like non-zero risk.

[HorlogeSkynet]

Indeed, let's keep them then 👍

[nir0s]

Can we close this? I generally agree that unless there's some overhead, there's no reason to "remove" support for Python versions.

Obviously, the views on this are very subjective. I'm with you in general (officially supporting only non-EOL versions). However, the reality is that many companies still run 2.6/7, even. I suggest that once we identify an overhead, we request that someone maintains a 3.6-support branch, just like we did with 2.7.

WDYT?