https://pantsbuild.org/ logo
Join Slack
Powered by
Important thread about when to end Python 2.7 supp...
# general
h
Important thread about when to end Python 2.7 support:
👆 4
âž• 2
As you probably know, Python 2.7 was sunsetted on Jan 1st 2020. Since then the Python ecosystem as a whole has been dropping support for it. Supporting 2.7 in Pex (and therefore Pants) imposes a maintenance burden. For example, it means that Pex cannot upgrade to vendoring newer versions of pip, so it can't pick up performance improvements and bug fixes there. So we'd like to know your thoughts on ending Python 2.7 support in Pants and Pex. Specifically, the proposal is that the upcoming Pants 2.13.x series will be the last Pants version to support Python 2.7, and that Pex will drop support for Python 2.7 soon after that. If you are using Python 2.7 and need continued support for it, or this proposal is a problem for you in some way, now is your chance to be heard!
b
My own personal opinion is to that the larger ecosystem tends to track supported Python versions. The more we support EOL versions of Python, the more we hold ourselves back from joining the larger ecosystem of tools and libraries. Although, the upgrade from Py3.X to 3.Y is much more stomachable than Py2.7 -> Py3.X
e
To clarify, Supporting 2.7 in Pex imposes no maintenance burden (my tests run fastest under 2.7 still!), it does impose a burden on non-Python 2.7 users though when a resolve of theirs is impacted by a Pip bug since fixed.
The maintenance burden vs Pex user burden tradeoffs and options are documented here as I saw it a few weeks ago: https://github.com/pantsbuild/pex/issues/1805
b
Supporting 2.7 in Pex imposes no maintenance burden
Well, we're limiting the support and contributions to people who still can do 2.7, and code which can straddle both.
e
I don't even know what that means - any person can do 2.7. They may not be willing to!, but then they're not a good candidate for contribution if that bothers them. As far as straddling goes, that is isolated in a 
pex.compatibility
module that changes rarely; i.e. that has been sorted for a long time now.
Basically almost all Pex needed work is hard enough in terms of paging in PyPA specs and real world packaging quirks, that that time compared to the time to learn the Python 2.7 way to read a file, say, is negligible.
b
but then they're not a good candidate for contribution if that bothers them.
I think that goes against the spirit of our community. I myself am turned off from making changes to Py2.7 libraries because it is more challenging to context switch. Saying that it isn't a cost is a lie I don't think we should tell ourselves. Your second message is likely true though. But then again Py2.7 adds yet another layer of comprehension
e
Well, keep in mind our community supports more than one tool. Pex was born from a ~non Pants contributor for the most part and has different aims. It strives to not break people. Pants moves faster. So I think respecting the tool user base / expectations trumps other considerations. IOW, if Pants has users wanting to contribute to it that want to write rules in Rust, because they know rust but not Python, we don't just stop and say sure and amend the rule system to support Rust as a way to write plugins.
Basically, my accounting of maintenance burden does not price in things that seem basic to the thing being maintained. To me, Pex is stable and that's priced in. Pants is extended via Python and that's priced in, etc.
IOW: A contributor has to meet a project at its goals I think or put in enough time to amend the goals with the project's community or simply not contirbute if those are daunting / not worth it for the contributor. I know when I've needed to fix coverage, for example, a good chunk of that is meeting Ned where his codebase is at.
h
Good points. I think part of the purpose of this thread is to assess the goals of Pants and Pex wrt Python 2.7. I.e., what does the community need or expect.
Supporting 2.7 in Pex imposes no maintenance burden
I don't think that's accurate, in that - as you state - it means we can't support 3.7+ with newer versions of pip, and working around that would require more maintenance. It also means we can't use Python 3 features in Pex code.
e
It also means we can't use Python 3 features in Pex code.
Yeah, that is obviously considered burdensome by some (most?) folks. It does not seem in spirit though with a stable library maintainer though as I understand that role. My gold standard was the Google librarians and they accepted the constraint of providing stability and the limits that placed on bumping to new language features, etc. I know there were definitely very creative and productive folks who used Guava and contributed some improvements, but were not willing to accept those constraints generally and so never became librarians / discontinued submitting patches for that reason.
Basically, as the maintainer I'm calling mild BS on the maintenance arguments. I think focusing on the good argument, support for Pip fixes as they come - which is what breaks users, will be more fruitful. Lead with the best argument and only resort to others if a tie break is needed!
h
Maybe my use of the word "maintenance" is more confounding than useful here. What I'm getting at is that we can't easily make forward changes we want to make to benefit Python 3 users, because of our support for Python 2.7. Word choice aside, that has been my argument all along...
e
Ok. I'm currently running the experiment of seeing if it actually is more maintenance in the traditional sense. Since Pip also has it's CLI as it's API and they also take keeping that compatible seriously, it could be that supporting both is in fact a 1 time maintenance burden (that being my current spike to check and see).
w
As someone with only 1 remaining project in 2.7 land (and how sorely I've wanted to migrate to 3.x, but can't due to largely "political" reasons at this moment)... It's not using Pants and it may or may not ever use it, but in any case I have the following questions: • Does any of the Pants telemetry give insight into what part of the Python userbase is still on 2.7? • I believe the general trend is to maintain support over the last 3 Pants releases, but in this case what level of support/patches would 2.13.x receive and over what duration? Like, would it just be the same as any other Pants release, or would it be some sort of LTS? • Are Pants and Pex necessarily in lockstep with regards to 2.7 support? As in, whether Pants keeps/drops it, could Pex keep it?
h
Well, the main cost right now is the pex issue alluded to above. if Pex finds a way to support 2.7 while also upgrading pip, then Pants can continue to do so for a while longer
e
What Benjy says is true. It's also true that Pex takes backward compatibility of it's CLI API very seriously. As such, it's likely you could always swap out Pants' Pex version for an older one. Sortof by definition, to be a good tool for Pants to use, Pex must be more stable than Pants over time (or else Pants would need to grow a bunch more conditional code), and it is.
It just struck me during a Pants upgrade of Pex that its probably best to focus this decision on Pants 1st. Pants can drop support for Python 2.7 freely from the Pex point of view. If it does, then that is one very big customer base of Pex that does not need Python 2.7 support. It may not be all, but certainly a large chunk I can stop worrying about over in Pex land while I'm wrestling with its super-set user base.
Circling back to this. Over in Pex I just completed my spike to see if Pex can support Pip 20.3.4-patched + Pip latest easily and it can (https://github.com/pantsbuild/pex/issues/1805#issuecomment-1214210479); so Pex will still be supporting Python 2.7.x and Python>=3.5 users ~indefinitely while still being nimble and supporting latest Pip and latest Python (3.11 rc is currently tested against). Pants can still make its own choices here independently and drop support for user code written in Python X if it wishes.
h
That’s good news
4 Views
Open in Slack
PreviousNext
Powered by