EOL python2 support - Githubissues

kbandla / dpkt

fast, simple packet creation / parsing, with definitions for the basic TCP/IP protocols

Other

1.08k stars 270 forks source link

EOL python2 support #551

Open crocogorical opened 3 years ago

crocogorical commented 3 years ago

Python 2 was sunsetted on January 1, 2020 (https://www.python.org/doc/sunset-python-2/).

Should dpkt drop support for python2 completely?

Stripping out existing support (much of compat.py, and the __future__ imports), and the requirement to call compat_ord when accessing byte members would simplify the code.

This would understandably be a breaking change, but perhaps could be part of a 2.0.0 release? Thoughts?

brifordwylie commented 3 years ago

Hi @crocogorical yeah, @obormot @kbandla and I have chatted about sunsetting Python2 support. There's a couple of conflicting observations here...

1) dpkt gets a lot of use in 'old' systems and we'd want to at least be aware/conscious of that. 2) Toolkits (like dpkt) need to evolve or die.. dropping Python2 seems fine/AOK to me at this point

My vote is to definitely drop Python2 support and as you suggest, Version 2.0 seems like a good place to do that.

crocogorical commented 3 years ago

I think clear signposting to 'known working' versions for 2.6 / 2.7 (in the README?) to allow continued installations on older systems seems like a good compromise.

If anyone is pip installing an actively developed package on to a python2 system and expecting the most recent version to work, they have high expectations for maintainers!

I'll tag this up with the milestone, and we can work out what else can go into the 2.0.0 release.

AiyionPrime commented 1 year ago

Is there anything I can help with in order to make some progress on this matter? I think having a support-branch for Python 2.6/2.7 would be a good idea.

So bugfixes and feature-backports would still be possible on it, but master could start aiming for python3 and make use of its features.

obormot commented 1 year ago

I think having a support-branch for Python 2.6/2.7 would be a good idea. So bugfixes and feature-backports would still be possible on it, but master could start aiming for python3 and make use of its features.

I like it. The latest 1.9.8 release has proven to be very stable so far. We've added 7 or so commits to master since then. Plan:

Create the python2-support branch off of the 1.9.8 commit tag;
Update README in master declaring python2 EOL, and announcing the python2-support branch off of a 1.9.8 release;
Backport the README to python2-support;
Remove py2 builds/testing in master;
Next release will be 1.9.9 and py3 only, give it soak time to ensure it's stable and push a 2.0.0 (yay!).

Sounds reasonable?

kbandla commented 1 year ago

This is the way to go. Going to do this.