New package: html5lib

[mgorny]

Last release in June 2020. Last commit in Feb 2024.

It's been forked already as html5lib-modern, then html5rdf — apparently primarily to remove the dependency on six. I've asked if they'd like to take the original over, but they weren't interested. Another project started a new tinyhtml5 library to avoid using the abandoned package.

I think reviving it, merging the existing test fixes and six dependency removal, and finally making a new release could stop this from escalating further.

[JelleZijlstra]

Good idea, I created https://github.com/compat-fork/html5lib-python .

Are you interested in doing the rest of the work in https://github.com/compat-fork/.github/blob/main/workflow.md (update the project name, get CI passing on the fork, etc.)? I just invited you to be a maintainer on the project.

[JelleZijlstra]

I also just invited you to be a co-owner of the organization. I know that you have a lot of experience in open-source work so I think you'd do a great job here. Feel free to add other projects too, and feel free to ping me if you'd like a second opinion on anything.

[mgorny]

I don't think I'll have time for this today, but I can look into it tomorrow.

That said, I'm slightly confused now — what's that about updating the project name? I thought the purpose would be to continue the original project.

[JelleZijlstra]

I have been renaming projects to "compat-fork-X" so I can publish them on PyPI without having to do a PEP 541 takeover. I guess it would be nice to use the original name (and if you'd prefer doing that, feel free to try), but using a new name unblocks publishing things faster.

[mgorny]

Unfortunately, that will just make this package yet another fork, and not improve the situation long-term. I'm not even sure if people can be swayed back into html5lib once they've already started forking it, but telling them to switch to another fork is unlikely to work either.

[JelleZijlstra]

True, feel free to stick with the html5lib name and try to take over the name.

My initial motivation arose when I needed to upgrade a package at work and it had some compatibility issues. There, it made the most sense to me to make a fork with a new name that I could put on PyPI immediately without having to wait for a PEP 541 request. However, your goals are somewhat longer term, which is great. I think we can amend the guidelines in the workflow document to allow retaining the original name.