Future of repoze.xmliter

[mauritsvanrees]

Is someone still interested in maintaining this package? Last release was in 2014.

Plone is still using this, including Plone 6.0 (alpha), specifically in the packages diazo, plone.app.theming, and plone.protect. Is anyone else using this package?

On Travis I see tests are run on Python 2.6, 2.7, 3.3 and 3.4.
Plone is actually running the repoze.xmliter tests, and until recently they were passing on Python 3.7, 3.8 and 3.9, so that is good. But with latests lxml 4.7.1 three tests fail. Looks easy to fix in the tests itself. I will create a separate issue for this. Fixed for now in Plone core by reverting to lxml 4.6.4. See also this discussion in plone.app.multilingual where we happened to discover the test failure.

Some ideas, if we want to put some new life in this repository:

• Switch from Travis to GitHub Actions.
• Drop Python 2 support.
• Drop support of Python 3.6 and lower, as these Python versions are no longer supported.
• Cleanup the code to match. I usually use black, isort5, and pyupgrade.
• Fix the tests.
• Make a major release 1.0.0.

This should not actually take too long, and I can probably do this. Do you agree with this plan?

I can create a PR in a fork, but I would also be happy to join the repoze organisation.
As Plone release manager I already have rights to release on PyPI, but I cannot make tags or otherwise push releases to master.

Alternatively, since @jensens is already in the repoze team, it would help if he gets pypi permissions. Actually, I can give him those. Done. :-)

[mauritsvanrees]

Cc the rest of the Repoze team:
@malthe @MatthewWilkes @mcdonc @tseaver

[mauritsvanrees]

Also, I wonder if it would be helpful to put Repoze under the umbrella of the Plone Foundation, just like Zope, Pyramid, and guillotina. But I don't have a big preference here.

[tseaver]

@mauritsvanrees I would be fine with the changes you propose. Please tag / make a beta release first, to allow for a smoother transition to the non-Py2 version in particular (to give people time to pin to < 1.0dev if needed).

[jensens]

I would add to not forget to release this as wheel too.

Any updates here otherwise?

[tseaver]

@jensens Why do we need (specifically) to release as a wheel? This is a pure-Python package, which can be trivially installed on any platform (assuming lxml is supported there) from an sdist.

[jensens]

@tseaver First it is the official recommendation, and for the pros I cite https://packaging.python.org/en/latest/guides/distributing-packages-using-setuptools/#wheels

You should also create a wheel for your project. A wheel is a built package that can be installed without needing to go through the “build” process. Installing wheels is substantially faster for the end user than installing from a source distribution.

[tseaver]

@jensens I bow to the recommendation, although I doubt that the "substantially faster" claim is measurable for a package as small as this one.

[malthe]

I guess it's also about not having to execute setup.py but just "unpack".

[mauritsvanrees]

Seems like all is done, except a release.

I have created a branch 0.x from before the major refactoring of the past few days. Thanks by the way, Tres!

[malthe]

I think I possibly wrote this package originally but I'm not an owner on PyPi.

[tseaver]

@malthe I went to go remedy that situation, only to discover that I'm not either. :)

[mcdonc]

I am not either

[mauritsvanrees]

I have invited all three of you on PyPI.