Any plans to make new release?

[kloczek]

I think that it would be good to flush currently committed changes and make new release :)

[dabeaz]

As noted at https://github.com/dabeaz/ply/blob/master/setup.md I plan no future "package releases" of PLY.

[Apteryks]

The page is now a 404. If this package is no longer maintained, could be be "archived" in GitHub with clear mention of its maintainership status? Thank you.

EDIT: The status is explained in https://github.com/dabeaz/ply/blob/master/CHANGES. It seems the author no longer plans to make releases, but fixes will be periodically synced in the repo. Does that mean that distributions should offer the latest commit?

[Apteryks]

Or should the latest tarball snapshot uploaded to this repo (https://github.com/dabeaz/ply/blob/master/ply-2022_01_02.tar.gz) be considered the latest stable release? I'm a bit confused, and I fail to see how that process is simpler than tagging a known good commit in git.

[dabeaz]

The ply-2022_01_02.tar.gz file is the latest release. I am quite serious about PLY NOT being a package-installed dependency---not even by git tag. People who want to use it should vendor it into their project as described in the README.

[Apteryks]

Hello, and thank you for the answer.

May I ask about the rationale for pushing against making this a package-installed dependency? Why is it deemed better to bundle it in source form? This should be documented, as it goes against distribution/packaging best practices that favors sharing as much code as possible via shared libraries to avoid maintenance spread.

Thank you!

[kloczek]

The ply-2022_01_02.tar.gz file is the latest release. I am quite serious about PLY NOT being a package-installed dependency

Issue is that at the moment at least few other modules have ply on its own install-time depedencies.

[dabeaz]

PLY is free software in the same sense as "free puppy." Meaning that you are free to have it, take it home, and train it to do whatever you want. However, the puppy is very much yours at that point.

I realize that this might not be the prevailing "best practice", but I'm not in business of being a critical free link on someone else's software supply chain. PLY solves a highly niche problem. Users of the library need to take full ownership of what they're doing. Although PLY doesn't change very often, I also want to be able to make changes to the library without worrying about breaking someone's "dependency."

[dabeaz]

Modules that depend on ply as an install-time dependency should either continue to rely on the last published version or vendor any future version that they intend to use.

[kloczek]

Any recommendation what should done in absence of ply? 🤔

[dabeaz]

If PLY works you can continue to use it by vendoring it into your project. It has no dependencies.