Repository navigation
Develop a long-term backport strategy #70
Description
In GitLab by @jaraco on Jun 11, 2019, 18:53
Leading up to the merge with Python 3.8, I maintained a cpython branch in this repo and I would merge changes from master into that branch and use that to port the changes into CPython. Since then, there have been some changes, some contributed to CPython and others contributed here. Up to the 0.18 release, all of the changes here seem to have been ported to CPython also, and only this change was contributed only to CPython (amended in 3c389f5), but even just that change means that the porting instructions are no longer valid. Moreover, the fact that some portions of importlib_metadata.__init__.py get ported to importlib.metadata and other portions go to importlib._bootstrap_external.py (and git has lost that ancestry), the cpython branch is becoming more of an impediment than a help.
At one point, I'd imagined that after the merge that CPython would become authoritative and importlib_metadata would be simply a backport... but that approach would preclude previewing/validating behavior in the more mutable external package first.
So I open this ticket for comment. What's the best strategy to keep these two codebases in sync? I can think of a few options:
- Require all changes to be applied only to CPython first and backport here.
- Require all changes to be applied to the backport first and forward-port to CPython.
- Allow the two codebases to diverge but try to keep them in sync as needed.
Other things to consider:
- Remove documentation from backport (rely entirely on docs in CPython).
How does the importlib_resources project inform this (or vice-versa)?
Activity
jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Jun 11, 2019, 18:55
changed the description
jaraco commentedon Oct 22, 2020
In GitLab by @mcepl on Jul 23, 2019, 13:29
With my hat of the large Linux distribution Python maintainer (openSUSE/SLE) I have intense dislike to all semi-backport packages. They tend to linger on and even when they are mostly unnecessary, we still have to fight how to get rid of
unittest2,linecache2and the likes. For this project I would therefore love it to be essentially dead, and all further development (and issue tracking) should be in the Python infrastructure. It is not 100% possible, because there is still need to support still maintained Python interpreters < 3.8, but aside from that, I would love this project to essentially go away.jaraco commentedon Oct 22, 2020
In GitLab by @warsaw on Jul 27, 2019, 24:14
I definitely appreciate that, but the problem is that we're really trying to kill off
pkg_resourcesand the only way I can see us doing that is to support alternatives all the way back to Python 2.7 (yes, likely even after January 2020).Of course, once
pkg_resourcesis removed from the ecosystem <wink> our job is done and we can retire this backport.jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 2, 2019, 13:59
The friction in a project like CPython means that any maintenance is slow and cumbersome. Moreover, the version of the project upstream doesn't have the sophisticated test infrastructure that this project has to test on various Python versions, check for style, coverage, and lint issues, etc. Therefore, I believe it's important to support contributions from either direction. In other words, I plan to maintain these two implementations by way of option 3.
jaraco commentedon Oct 22, 2020
In GitLab by @jaraco on Sep 2, 2019, 13:59
closed
Make substitution fields more prominent and distinct from true 'skele…
Merge branch 'feature/run-everywhere' into 'master'