2.7 support dropped?

[schmonz]

Is it true that ApprovalTests.Python no longer runs under 2.7? If so, and I've got a legacy 2.7 codebase I want to modernize, what's a good way to get ApprovalTests around it?

[obestwalter]

I don't think that Python2 was actively supported for quite a while, but we made it explicit about a month ago. So any version released before might be able to be be used with Python2 still. This one has not explicitly dropped py2 support yet: https://github.com/approvals/ApprovalTests.Python/releases/tag/v0.3

[schmonz]

I guess I'm sad to hear this was intentional. Legacy code is a context in which ApprovalTests particularly shines, and it'll be a long time before the world runs out of pre-Python3 codebases that need help from all the modern tooling they can get.

I know maintaining 2.7 compatibility isn't free, but I'm having trouble imagining that saving that maintenance cost is worth the loss of applicability to countless otherwise extremely applicable codebases. Would you (plural) be willing to share some of the reasons for the decision to drop 2.7? Are there conditions under which you'd reverse the decision?

[obestwalter]

I guess I'm sad to hear this was intentional.

I just looked into the history and the py27 tests where dropped end of last year when moving from travis to GH actions. I hadn't joined the project then, so don't know the background. Maybe one of @isidore, @tdpreece, @emilybache, @claremacrae, @objarni can chip in?

I know maintaining 2.7 compatibility isn't free, but I'm having trouble imagining that saving that maintenance cost is worth the loss of applicability to countless otherwise extremely applicable codebases.

You have a point there.If approvaltests could help to port py27 code to Python 3, it could be worth keeping it compatible with py27 as long as it is not too painful for the developers. The longer Python 2 is EOL the more painful it will get to support it, though. It is also hard to say how many and which projects would profit from this backwards compatibility. Could you point to a few concrete projects?

[objarni]

@schmonz would you be willing to join the ensemble for this library to help out bringing 2.7 support in again? It would mean dropping any f-strings, Path's and other "modern" niceties we've been able to use lately. It also means dropping ideas of type annotations that @isidore has been wanting a long time (available only since Python 3.5).

I wish there was a middle way which would enable use of a modern ApprovalTests.Python library, on legacy code. But I guess that's a pipe dream...

[obestwalter]

Maybe there is a place for an approvaltests-py27 based on a fork of 0.3? That project could then be generously funded by corporations that rely on it to maintain their unported code.

[obestwalter]

Had a quick look how far we strayed already - would be pretty easy to go back to py27 support at the moment: https://github.com/approvals/ApprovalTests.Python/compare/master...obestwalter:py27-compat?expand=1

[schmonz]

I’d love to join the ensemble sometime and help restore 2.7 support. Probably some of the Python 3-isms have been backported, so we can at least keep those (at the cost of some additional dependencies for 2.7 users, which seems cheap). Maybe there are creative ways we can keep the other 3-isms too.

[obestwalter]

I’d love to join the ensemble sometime and help restore 2.7 support. Probably some of the Python 3-isms have been backported, so we can at least keep those (at the cost of some additional dependencies for 2.7 users, which seems cheap). Maybe there are creative ways we can keep the other 3-isms too.

Hi @schmonz, I also thought about this a bit more over the last few days as I think this is an important topic. For this reason: please forgive me, when I flesh this out a little more than maybe necessary to make my point.

Python2 is really dead

Python2 is finally, really, really officially dead for over a year now. And me personally, I am really, really glad that it is. I learned Python, when it was 2.6 and was stuck on 2.7 until around 2016, when we finally where able to port the corporate code base to Python3. I had to deal with Python2 compatibility much longer in the OSS projects I was involved in and it caused a not insignificant amount of extra work, testing, etc. ... and the constant feeling that you can't make use of the new features and optimizations of the language.

I am personally very grateful to the community that it kept Python2 alive for far longer than originally planned to give every one enough time to migrate their code bases, but this time is now finally over. And it really should be over. For good. At least as far as volunteer driven FOSS projects are concerned.

It was worth the effort and I played along and did my tiny part in helping to make the migration easier, but speaking just for myself: I am tired of doing so and I wouldn't do it for free anymore. At least for me, it's as simple as that.

In my very strong opinion, Python2 has stopped being a community effort last year and now it is an Enterpri$e$upportEffort(TM). There are companies doing this (keeping the Python2 interpreter ticking over for another decade or so), but even they woke up and smelled the coffee with regards to the massive FOSS ecosystem around the language:

Community Python Packages

Most community authors and maintainers of third-party Python packages have either stopped support for Python 2, or are intending to stop support for Python 2 in 2020.

The expectation has been set that extremely few community Python packages will continue maintenance or support for their Python 2 versions into the future.

-- https://access.redhat.com/solutions/4455511

Is it necessary for this project to stay backwards compatible?

So the question remains, if the python flavour of approvaltests should be one of the "extremely few community Python packages" supporting Python2 in the future and my current favourite answer to that would be a clear yes and no. In practice this yes and no could look something along the lines of:

• we can build and publish a new package that is based on the current code, with my small adjustments I made to port back the current master to Python2 - I would be willing to help with that, to get it off the ground
• we can make the following adjustment to the main approvaltests project to point legacy Python users in the right direction: if someone types pip install approvaltests from an unsupported Python version, they get an install failure with a friendly help message that approvaltests is Python 3 only but that there is an alternative available via pip install approvaltests-legacy
• whoever is willing to support approvaltests-legacy, can then keep it compatible to whatever range of Python interpreters they deem appropriate (e.g. Python2 up to newest Python3.x that is already EOL (currently 3.6 is the last supported Python3 version, I think))
• If @isidore agrees the project could also be hosted in this organisation - this is not necessary, but I think the level of helpfulness of the error in the main project will depend on that, as the owner of the project needs to be comfortable with endorsing a legacy port of the tool right from within the installation routine of the main project

That would be the approvaltests specific solution that I personally would be happy with, as I am really looking forward to keep helping with the development of the project, but I really do not want to be held back by Python 2 compatibility. My personal reasons are like already hinted:

a) I like to play with the new toys in my side projects to keep learning and keeping my skills up to date
b) I don't want to have a constant nagging feeling that I am going through the extra pain of not being able to do a) just so that not clearly defined (but very likely commercial) entities can have a free testing tool for their unported Python 2 code.

Are there other tools, solving the same problem?

The one that I know of that helps with all kinds of legacy projects without needing a library that is compatible with its own code at all, is TextTest. It is a standalone tool (even with a nice GUI) that can work with all kinds of text generated by the Code Under Test. So it could be worth looking into that instead, if there is no compatible approvaltests library available.

Conclusion

So given all that, I am a strong -1 regarding regressing to Python2 for the main project, but would be willing to help, getting approvaltests-legacy off the ground (and then let somebody else with actual skin in the game maintain that (and that might even be future me, but very definitely not current me)).

So if you like to team up and if @isidore is willing to go along with the legacy package approach, we could join up for a mob session to get this off the ground. With the current automation in place, it shouldn't be too much fuzz to get it done and have a pleasant process, just like the main project. The ongoing maintenance and backporting of new features from the main project could then be headed up e.g. by you and other volunteers in the legacy game.

[schmonz]

@obestwalter, thank you for your care and effort in formulating your thoughts here. I have to admit, I had indeed been imagining some future commercial client needing help with a 2.7 codebase. Your reminder about TextTest is a useful one.

My proximate wondering, though, was as a packager. I maintain the py-approvaltests package in pkgsrc, a cross-platform Unix package manager. Keeping it up-to-date had been uneventful until I recently noticed Python 2.7 builds failing, which I hadn’t recalled seeing anything about in any release notes. That’s why I popped up in your issues asking what’s intended with 2.7 here. :-)

From pkgsrc’s point of view (and probably any other OS package manager’s), it will be a long, long time before the dependency graph of our complete set of packages can be drawn without once needing Python 2.7. As soon as that’s true, I expect we’ll delete lang/python27 from our repo with great eagerness. In the meantime, as a packager, I have to do something about the build breakage. Armed with the knowledge that dropping 2.7 was mostly intentional and we won’t solve it in this week or probably even in this project, what I’ll do for today is simply mark the package as not for 2.7, and maybe also provide a pinned version of the last 2.7-compatible release.

That’s all the skin I currently have in the game. I like your idea and certainly wouldn’t want to stop anyone reading this from getting there before future-either-of-us can.

I’m happy to see this issue closed if it serves no further purpose for the project, or having it left open if there’s more to be figured out and this is a good place to do it.

[obestwalter]

My proximate wondering, though, was as a packager. I maintain the py-approvaltests package in pkgsrc, a cross-platform Unix package manager. Keeping it up-to-date had been uneventful until I recently noticed Python 2.7 builds failing, which I hadn’t recalled seeing anything about in any release notes. That’s why I popped up in your issues asking what’s intended with 2.7 here. :-)

Ah, it's always interesting to see what kind of packaging is happening around the actual projects that the maintainers have no awareness of. Thanks for your work there ❤️

what I’ll do for today is simply mark the package as not for 2.7, and maybe also provide a pinned version of the last 2.7-compatible release.

Yes, for this package I think that is the correct thing to do. We have set the metadata correctly a few weeks ago to reflect that, in case packaging uses this as input.

I just had another look until when it could be expected to work with Python 2 and it looks like it was even before 0.3. CI for py27 was dropped in d2d99df already and the release before that was 0.2.10, so I guess that is the one that can be marked as py27 compatible for now.

That’s all the skin I currently have in the game. I like your idea and certainly wouldn’t want to stop anyone reading this from getting there before future-either-of-us can.

If anyone is motivated to get a newer version of the code working with Python 2, I think the best way would be to backport it from the then current code. Right now development is quite active here and a lot of important changes are introduced, so it wouldn't even make too much sense, to fork it now. Let's see how it develops.

I’m happy to see this issue closed if it serves no further purpose for the project, or having it left open if there’s more to be figured out and this is a good place to do it.

I would propose to close this, as the current decision is that py2 support stays dropped. Whoever stumbles into the issues next to look for Python 2 support will hopefully find it.

[claremacrae]

It would probably be worth pinning this issue, to help others find it easily.

[obestwalter]

Closing and pinning? Or leaving open for now?

[claremacrae]

I'd suggest Closed if no action is planned - and Pinned so it stands out...

[claremacrae]

It turns out I have permission to pin it, so I've done so...