dabeaz / ply

Python Lex-Yacc
http://www.dabeaz.com/ply/index.html
2.79k stars 465 forks source link

Ongoing maintenance #217

Closed jayvdb closed 5 years ago

jayvdb commented 5 years ago

@dabeaz it seems you are no longer interested in acting as a maintainer any longer, and it is not true that ply no longer needs maintenance - even Python the language continues to evolve, and all packages need updating as the language improves. And improvements need versioned releases.

https://repology.org/project/python:ply/versions shows the third parties that are redistributing ply, and they have no option except doing that because there are many projects who have not vendored ply, and frankly I doubt many projects will vendor ply, as they dont want to go down the vendoring path as vendoring tools are based on versions and the ply project says it wont version so the vendoring tools are not going to work. Instead a fork will happen, and current users will switch, so that there is a centralised approach to ongoing maintenance of ply.

An approach to avoid that is to move the repo over to @jazzband, which have a proven record of maintaining Python libraries that are feature complete, or add collaborators you trust to maintain it in a manner you are happy with.

dabeaz commented 5 years ago

PLY is mature software that implements a very specific parsing algorithm from the 1970s. It is small. It currently works perfectly fine with Python 3.8. Maintenance, when it is required (which is almost never), usually occurs in short sprints.

My decision to no longer make pypi releases is pretty simple. PLY is a tiny library that solves a very specific niche problem in compiler/parsing writing. It's the kind of thing that gets buried within significantly larger packages and frameworks and quickly forgotten about--which is all fun and games until two different frameworks decide they want to use different PLY versions and all hell breaks loose. Then, there's the fact that I can never make any backwards incompatible changes or improvements to the library because of all of these critical dependencies.

I'm done with dealing with all of that. I am not going to be the critical link on other people's projects. If you want to use PLY in a project, then take some ownership/responsibility and COPY it into your project as a subpackage. This eliminates the problems of PLY conflicts with other projects and it frees me to make future changes that might break backwards compatibility.

If people can't accept this, then they are more than welcome to go get the Dragon Book and code up the LALR(1) algorithm from scratch. Or go use some other parsing project.