This is an archive of the discontinued LLVM Phabricator instance.

[LNT] Remove Python2 support
ClosedPublic

Authored by thopre on Oct 16 2019, 9:42 AM.

Details

Summary

This patch removes all the Python 3 compability imports, thus removing
Python 2 support.

Python 2 is no longer maintained since Jan 2020, a year and a half already.
Perhaps it is time to remove Python 2 support in LNT.

Event Timeline

thopre created this revision.Oct 16 2019, 9:42 AM

FWIW, we are still using python2 everywhere. I think the python3 version needs to stew for a bit so we can find any bugs that might have been introduced.

FWIW, we are still using python2 everywhere. I think the python3 version needs to stew for a bit so we can find any bugs that might have been introduced.

Oh yes absolutely. I don't think tests cover all issues so we'll find more. I'll be using LNT in Python 3 mode as soon as all the patches have landed so hopefully I'll uncover a big portion of those. In terms of timeframe I was thinking end of 2020. While Red Hat will have supported versions with Python 2 for a long time yet I think that's a too long time to wait. Does that sound reasonable?

thopre edited the summary of this revision. (Show Details)Dec 6 2019, 4:34 AM
Andi added a subscriber: Andi.Feb 2 2020, 10:07 AM
thopre retitled this revision from [LNT] [WIP] Remove Python2 support to [LNT] Remove Python2 support.Sep 3 2021, 2:41 AM
thopre edited the summary of this revision. (Show Details)

Ohh it's happening!

This looks good but you've missed the cPerf stuff, https://github.com/llvm/llvm-lnt/blob/f48d431f44610e339d00a33d57564c6029c4ff43/lnt/testing/profile/cPerf.cpp#L827 and lnt/testing/profile/__init__.py

thopre added a comment.Sep 3 2021, 3:20 AM

Ohh it's happening!

This looks good but you've missed the cPerf stuff, https://github.com/llvm/llvm-lnt/blob/f48d431f44610e339d00a33d57564c6029c4ff43/lnt/testing/profile/cPerf.cpp#L827 and lnt/testing/profile/__init__.py

What's Python2 specific in lnt/testing/profile/__init__.py?

thopre updated this revision to Diff 370526.Sep 3 2021, 3:20 AM

Remove cPerf Python2 code

Ohh it's happening!

This looks good but you've missed the cPerf stuff, https://github.com/llvm/llvm-lnt/blob/f48d431f44610e339d00a33d57564c6029c4ff43/lnt/testing/profile/cPerf.cpp#L827 and lnt/testing/profile/__init__.py

What's Python2 specific in lnt/testing/profile/__init__.py?

The futures import at the top https://github.com/llvm/llvm-lnt/blob/f48d431f44610e339d00a33d57564c6029c4ff43/lnt/testing/profile/__init__.py#L4

thopre added a comment.Sep 3 2021, 3:27 AM

Ohh it's happening!

This looks good but you've missed the cPerf stuff, https://github.com/llvm/llvm-lnt/blob/f48d431f44610e339d00a33d57564c6029c4ff43/lnt/testing/profile/cPerf.cpp#L827 and lnt/testing/profile/__init__.py

What's Python2 specific in lnt/testing/profile/__init__.py?

The futures import at the top https://github.com/llvm/llvm-lnt/blob/f48d431f44610e339d00a33d57564c6029c4ff43/lnt/testing/profile/__init__.py#L4

It's already there: https://reviews.llvm.org/D69056#change-H7ZXp1LFQQlR

Ohh it's happening!

This looks good but you've missed the cPerf stuff, https://github.com/llvm/llvm-lnt/blob/f48d431f44610e339d00a33d57564c6029c4ff43/lnt/testing/profile/cPerf.cpp#L827 and lnt/testing/profile/__init__.py

What's Python2 specific in lnt/testing/profile/__init__.py?

The futures import at the top https://github.com/llvm/llvm-lnt/blob/f48d431f44610e339d00a33d57564c6029c4ff43/lnt/testing/profile/__init__.py#L4

It's already there: https://reviews.llvm.org/D69056#change-H7ZXp1LFQQlR

Oh I had missed it :D

Thanks! this looks complete now.

I guess the only question is, should we bump up the version number? to make a clear line in the sand? otherwise it's hard to tell people which version supports python 2 (in case they need to run an older one for whatever reason)? or more importantly, tell which one is python 3.

thopre added a comment.Sep 3 2021, 3:41 AM

Thanks! this looks complete now.

I guess the only question is, should we bump up the version number? to make a clear line in the sand? otherwise it's hard to tell people which version supports python 2 (in case they need to run an older one for whatever reason)? or more importantly, tell which one is python 3.

Good point. We are currently in 0.4.2dev0 so perhaps we should tag a 0.4.2 first and then pass to 0.4.3dev0?

Thanks! this looks complete now.

I guess the only question is, should we bump up the version number? to make a clear line in the sand? otherwise it's hard to tell people which version supports python 2 (in case they need to run an older one for whatever reason)? or more importantly, tell which one is python 3.

Good point. We are currently in 0.4.2dev0 so perhaps we should tag a 0.4.2 first and then pass to 0.4.3dev0?

Perhaps 0.5 instead? that would give someone wanting to continue Python 2 support for whatever reason a way to continue in the 0.4.x ranges?

Thanks! this looks complete now.

I guess the only question is, should we bump up the version number? to make a clear line in the sand? otherwise it's hard to tell people which version supports python 2 (in case they need to run an older one for whatever reason)? or more importantly, tell which one is python 3.

Good point. We are currently in 0.4.2dev0 so perhaps we should tag a 0.4.2 first and then pass to 0.4.3dev0?

Perhaps 0.5 instead? that would give someone wanting to continue Python 2 support for whatever reason a way to continue in the 0.4.x ranges?

Good point, release 0.4.2 and then change version to 0.5.0dev0 on the main branch. If we realize we want to do more releases with Python2 we can create a python2 branch from the release but I think we should not do it preemptively. Thought @cmatthews ?

Thanks! this looks complete now.

I guess the only question is, should we bump up the version number? to make a clear line in the sand? otherwise it's hard to tell people which version supports python 2 (in case they need to run an older one for whatever reason)? or more importantly, tell which one is python 3.

Good point. We are currently in 0.4.2dev0 so perhaps we should tag a 0.4.2 first and then pass to 0.4.3dev0?

Perhaps 0.5 instead? that would give someone wanting to continue Python 2 support for whatever reason a way to continue in the 0.4.x ranges?

Good point, release 0.4.2 and then change version to 0.5.0dev0 on the main branch. If we realize we want to do more releases with Python2 we can create a python2 branch from the release but I think we should not do it preemptively. Thought @cmatthews ?

Ping @cmatthews ?

I think this would be safe to land now. Are you still interested in landing it?

Herald added a project: Restricted Project. · View Herald TranscriptMar 14 2022, 3:45 PM

I think this would be safe to land now. Are you still interested in landing it?

Yes, let me rebase and see if testsuite is still passing.

This revision is now accepted and ready to land.Mar 15 2022, 9:52 AM
This revision was automatically updated to reflect the committed changes.
lnt/util/wsgi_restart.py