Backport recent fixes to 5.7.5 release with Python 3.8 and later compatibility #340
Conversation
dnicolodi
force-pushed
the
py38_again
branch
4 times, most recently
from
24a1fd4 to
7196548
Compare
|
One of the reported linter errors is present on the master branch too, fixed in #341. The others emerge after the changes in this PR, but AFAICT they are not related to the changes proposed here. |
|
@dnicolodi, I don't remember how we did this the last time. Merging to I can create a All tests should pass, even if it means patching them on the branch . |
|
I looked at the few warnings from |
|
Sure, I didn't want to propose to merge this into Creating a release branch would be the way forward. If there would be more tweaks required, we could have a Sure, all the test should pass before merging. |
With |
|
The PERF203 by You'll have to merge from upstream to update the pull request. |
|
Rebased on |
|
@dnicolodi I need to create a branch so you can target this pull request there, and it's done! The branch is Target the pull request there so there is no interference with |
|
I changed the target branch for the PR to |
|
Merged! Let me take a moment to think about the release process (I don't remember what I did the last time). |
|
Thanks @apalala ! I may be stating the obvious, but it looks like you can simply select the branch to tag when creating a new release. I don't think TatSu uses automation for building wheels, thus uploading to PyPI would also require checking out the tag, building sdisgt and wheel and upload them to PyPI. |
|
Sorry for the delay. I'll get onto this shortly. |
|
@apalala It would be nice to push a release with these fixes. Thank you! |
|
Hello @apalala. Are you still interested in supporting older Python releases with releases in the 5.7 branch? I was looking into backporting other commits from main to this branch, but if you think that it is not worth to have more releases supporting Python 3.8 and later, I'll need to find another way to support my use case. If that is the case, I completely understand and I don't want to push you to do work that does not benefit your use cases, and I'll find another way to support my use cases. I'll most likely fork this project under a different name and do releases following TaTsu releases, just with support for older Python versions. |
|
Hi @dnicolodi, I was thinking about this effort recently, and meant to write. I think that the bes approach to carry on is for you to fork TatSu and publish the results to PyPi under a different but simliar name. I think that at some point it will become very difficult to maintain compatibility with Py 3.7 and 3.8, but that moment hasn't come. |
|
Thanks @apalala. I can definitely do that. Would you be happy with
I already dropped support for Python 3.7. 3.8 is still easy but I'm ready to drop it as soon as it requires too much work. I would like to support all non-EOL Python versions. Currently, this is 3.9 and later, but at the moment keeping support for 3.8 does not require any extra work. |
|
Let's do it! I thought about other names for the PyPi project, but I would add a prominent note pointing to this new project on the docs just under the paragraph that says that non-active versions of Python are not supported. I suggest that for versioning you use the TatSu version of the last fork with a tag for the oldest Python version supported: or something like that. There's no work on new features in TatSu, and I see no need to use the newer syntax in maintenance. I imagine that third party libraries are taking care of the changes in the |
|
Oh! And I can still merge pull requests that help with LTS compatibility. |
That was just the first thing that made sense that came to mind. I'm not particularly attached to it. I'm open to your suggestions, if you think there is something better.
I'm not sure this is a valid version identifier. Anyhow, Python compatibility is recorded in the package metadata, thus adding it to the version number does not seem important to me. I was thinking to use the same version number as used in TatSu. That would avoid any confusion by users. I'll setup this as soon as possible and I'll send a documentation patch. |
|
No one asked for my opinion, but since I'm getting emails for all of the PRs and issues now, I figure I'll chime in with my $0.02. IMO, I don't think it's a good idea to divorce this from the primary repo. Discovery of the package will be difficult and IMO confusing. Users will have to search Pypi and determine which package they want unless this repo starts advertising this LTS package as an "authorized maintenance fork", which is going to be maintained by another user than the primary repo. Even then, maintenance within the same repository would be much easier from a collaboration POV as well as in colocating issues, PRs, design discussion, etc. When someone has a problem, do they open an issue with the LTS repo or the base repo? maybe it affects both? That determination is easier when not done in isolation. IF this gets forked off, I don't think the python support version needs to be encoded in the tag name, it's advertised in the pyproject.toml/project metadata unless this is just a convenient way to know at a glance. It could be useful to encode the base tag in the LTS tag name so the "origin" is known at a glance when browsing the repository, but it's not necessary from a packaging perspective since you will be publishing under a new package name. You could pick up where upstream left off (version = 5.7.6 # taken from upstream 5.7.5) I'm going to soapbox a bit and just say that the narrow version range of this base repository being at the upper end of the python release cycle is a little problematic, especially if the desire is for "professional use" of the tatsu library. By this October, you will be requiring 3.13/3.14. The only distribution i'm aware of with support for 3.13 is Fedora which is bleeding edge. Distributions with LTS support like Ubuntu 24.04 are still on 3.12. Enterprises move rather glacially and don't time their migrations well. Some are likely still using Ubuntu 20.04 which doesn't go EOL until April '25 and may not migrate until after that EOL date. This means they're either using python 3.8 or 3.9. Debian Bullseye still uses 3.9 and Bookworm, which goes EOL in 2028 is using 3.11. Updating may require a migration to a newer distro, reworking their application deployments via containers or pyenv or any number of other things, just to accommodate using newer versions of tatsu with fixes. By this The level of effort to support 3.10+ should be minimal as all linters and unit tests pass. 3.9 may have problems with types since there was lot of work done to clean up the typing interface in 3.10, but 90% of those are probably changing Long term, I think establishing an annual cadence to match CPython's release and EOL cycle would be easy enough. Users can slowly migrate from X.y to X.z or Y.x which will slowly drop the last python version, and then the minimal linting configuration can be bumped. or at least specifying "X.y is an LTS branch", fixing the dependencies to be pinned to specific versions (mypy/ruff), disabling preview mode on ruff since that's a moving target and not finalized (fine as a canary check, but generates way too much noise on the master branch and would be detrimental on a LTS branch). Porting patches back to LTS branches can be on an as-needed basis. I'd probably recommend just using 5.7 as the cut off point prior to python 3.10 and port fixes back to that version as needed, then establish a new LTS version that supports 3.10+ with new release semantics. Also, a published changelog would be useful so users migrating could get a sense of what's changed between the versions without having to grok the commits which don't have a lot of documentation about what's changing and why and how that affects them. |
The new package would be advertised on TatSu's Github page and the docs. The thing is that I don't have time to work on compatibility with deprecated versions of Python, yet I would like to collaborate if someone wants to maintain that. @dnicolodi has been waiting for me to publish a TatSu release that incorporates the backwards compatibility, and I know longer remember how to do that, nor which te version number should be. In my opinion forking is the best option. @dnicolodi would be free to publish whenever, and we can still keep talking about how to keep the main TatSu friendly to older versions of Python. I disagree with wanting to use Python 3.8 after the anual releases cycle has made 3.11 security-fixes-only, but I can leave with that as long as TatSu is not bound to that. |
|
I agree that having TatSu drop support for older versions of Python less aggressively would be the best thing. But that does not fit with @apalala vision. Free Software development should be fun and @apalala does not have any obligation to spend energy on something just because "it would be better". The only way to be sure to make something happen in the Free Software ecosystem is doing it yourself. I'm up for maintaining a TatSu-LTS with the Python compatibility guarantees explained above and I don't see much of a problem in doing it. |
And I will help! I just want out of testing compatibility with legacy versions of Python and of publishing. @dnicolodi would have to maintain a |
|
I've just published TatSu-LTS 5.12.2 https://pypi.org/project/TatSu-LTS/ This was mostly a test run for the process and 5.13.0 will follow shortly. Some further updates to the documentation and to the project metadata are likely necessary. The git repository is here https://github.com/dnicolodi/TatSu-LTS |
|
I modified I'll push the changes, and publish a 5.13.1 when you're ready. |
|
I've just uploaded TatSu-LTS 5.13.0. I would like to submit a documentation patch to mention the LTS project (and a few README cleanups, while at it). If you can wait till tomorrow with the release, we can have this included in 5.13.1. Otherwise, it will be included in the next release. I would also like to submit a PR modernizing the CI setup a bit, but this can definitely wait. |
|
Which is the repo, @dnicolodi ? |
|
https://github.com/dnicolodi/TatSu-LTS/ There is a |
Similarly to what we did with the 5.7.4 release, I would like to backport the recent improvements and bug fixes in a release compatible with Python 3.8 and later. This PR contains the changes required on top of the current master branch to support Python 3.8 and later. It would be great if this could become a 5.7.5 release. @apalala What do you think?