GitHub Actions Remove Python 2

[DaAwesomeP]

The setup-python action no longer supports Python 2.7. See actions/setup-python#672.

Found in #1863. Finding this kind of issue would be helped by #1862.

[peternewman]

😢 While I'm sure this makes more sense than fighting to replicate GitHub stuff, it's a bit of a shame for me...

[DaAwesomeP]

cry While I'm sure this makes more sense than fighting to replicate GitHub stuff, it's a bit of a shame for me...

I am fortunate to not be running anymore Python 2 applications anywhere, but as I also maintain some RHEL machines...I definitely understand the feeling when either your machine won't support new software or the new software won't work with something older. It's like externally created tech debt. If I may ask, what is still stuck in Python 2 for you?

Since at this point it is often not trivial to obtain Python 2 on many of the current LTS/stable distros, I think it might be worth at least discussing deprecating Python 2 in 0.11.

[peternewman]

I am fortunate to not be running anymore Python 2 applications anywhere, but as I also maintain some RHEL machines...I definitely understand the feeling when either your machine won't support new software or the new software won't work with something older. It's like externally created tech debt. If I may ask, what is still stuck in Python 2 for you?

It's mostly a bit of what you say, having a load of old stuff running and not wanting to have to jump ahead and make sure it all works on the new system, plus there are still a small handful of bits I'm not entirely convinced we've properly scoped out or fixed when migrating to Python 3, so if I lose the ability to test it on Python 2 I can't tell you what the original behaviour was as to whether we've broken that/improve the tests to ensure we aren't.

My general feeling is that if it's not too arduous for us to add something, or as long as someone is willing to add it, we should try and keep it if possible. There's nearly always a crossover period where we need to support both (be that libusb or Python or whatever), so we can, it's just down to how much people care if the older one goes, and perhaps more crucially how often we're testing that we haven't broken it.

Since at this point it is often not trivial to obtain Python 2 on many of the current LTS/stable distros, I think it might be worth at least discussing deprecating Python 2 in 0.11.

My thought always has been, and I think still is, to drop it in 0.12.0, given there's not that much different between 0.10 and 0.11 codebases, it's a shame to not offer people all the new features we've been working on (like KiNet) with all the old support they're used to too.

[DaAwesomeP]

plus there are still a small handful of bits I'm not entirely convinced we've properly scoped out or fixed when migrating to Python 3, so if I lose the ability to test it on Python 2 I can't tell you what the original behaviour was as to whether we've broken that/improve the tests to ensure we aren't.

That is a very good point. Maybe we should look into getting Python tests into coverage/Coveralls to help with that. Then we can be really sure we got everything.

My general feeling is that if it's not too arduous for us to add something, or as long as someone is willing to add it, we should try and keep it if possible.

That is entirely reasonable. You're right; there hasn't necessarily been anything blocking Python 3 usage because of Python 2.

My thought always has been, and I think still is, to drop it in 0.12.0, given there's not that much different between 0.10 and 0.11 codebases, it's a shame to not offer people all the new features we've been working on (like KiNet) with all the old support they're used to too.

Makes sense!

[peternewman]

That is a very good point. Maybe we should look into getting Python tests into coverage/Coveralls to help with that. Then we can be really sure we got everything.

Yeah that would be awesome, but obviously generally the more matrix of coverage the better (be that GCC versus clang or different libusb versions etc), the more of our paths we can check. Assuming it can merge multiple bits of coverage for the same commit/release/version. Maybe some of the more detail ones should only say be run on pushes to branches, to avoid burning too much processing when people are mostly not looking at it.

My general feeling is that if it's not too arduous for us to add something, or as long as someone is willing to add it, we should try and keep it if possible.

That is entirely reasonable. You're right; there hasn't necessarily been anything blocking Python 3 usage because of Python 2.

Yeah I think there's just some tidying up possible and that's about it, but that itself needs work and testing afterwards, so the benefit is questionable.