Future plans for zest.releaser

[mauritsvanrees]

For background, a small bit of history up front: me and my brother @reinout both worked for Zest Software about 15 years ago. It is a small software company in The Netherlands, at the moment three people: Jean-Paul, Fred and me. Reinout created zest.releaser, and since then we both did a lot of work on it. According to LinkedIn he left in 2009, but I stayed and am still there. We two are the only maintainers.

Because I am Plone Releaser Manager, I probably use zest.releaser a lot more than he does now. Me and my colleagues use it often, and many people in the Plone community as well. Latest Plone release 5.2 supports Python 2 and 3. Version 6 is expected within a few months and will only support Python 3. In the Plone world and the Zest world, git is the only version control system. More broadly, in the Stack Overflow Developer Survey 2021 over 90% of developers use git.

I think development on zest.releaser may be a bit too difficult at the moment, certainly for outsiders who may want to create a pull request. We test subversion, bazaar, mercurial, git. Python 2 and 3 plus PyPy. To run the tests, you need to use buildout. And we have this weird test setup with z3c.testsetup, with I think even Grok-like behavior. And doctests. Can we make this simpler?

Some ideas for future simplification:

• Drop support for Python 2.7 (and PyPy2). Pretty obvious.
• Probably drop support for Python 3.5 and 3.6. Python 3.10 is around the corner, so we should start testing it. Keeping PyPy3 would be cool though.
• Switch from Travis to GitHub Actions.
• Drop support for subversion, bazaar and mercurial. Git has won, at least in my backyard.
• Allternatively, since supporting multiple VCSes is not too hard, only the testing of it is hard (and time consuming): change the tests to only do the full tests for git by default. Test git on all Python versions. Test the other version control systems only basically and only on one Python version. That should be doable with tox and GitHub Actions.
• Get rid of buildout in the tests. Just install what we need with pip. We also use buildout to generate the Sphinx documentation I think, so maybe something needs to be left. I don't really know how this is done.
• Get rid of doctests. They have their uses, but as some people like to say: they are neither documentation nor tests.
• Get rid of z3c.testsetup. Maybe use pytest.

We can continue to do bug fixes for the current 6.x release.

Some stuff is easy to do on short term:

• Drop support for Python 3.6 and older and run pyupgrade.
• Switch to GitHub Actions.
• Maybe also: let one test run only use one VCS, probably via some environment variable. Default to git. Test git on all Python versions, and the others only on one, perhaps 3.8.
• Release this as 7.x.

@reinout What do you think?

[reinout]

I still use it a lot myself. And it is standard for all python packages in my current company, too. There even is a plugin that I wrote that we use regularly: qgispluginreleaser :-)

• Buildout => pip, yes
• pytest: yes, please.
• Drop subversion and bzr: yes. (Note: the test-docker that's included lets me run the tests just fine, btw).
• Drop mercurial: probably yes. (At least, I don't use it anymore and the main mercurial hoster, bitbucket, also dropped it).
• Python: 3.6+, I'd say (ubuntu 18.04)
• Sphinx: buildout isn't needed for that, the buildout sphinx recipe is just a small wrapper. I can fix that quick enough.
• Github actions: yes.

And... I'd love to pour "isort" and "black" over the code. I still haven't done it as there are a few PRs we might want to look at first.

[mauritsvanrees]

I am in favour of isort and black as well. There are only two open PRs and they have been open since 2015 and 2017. And they are both about encodings, so they might be fixed already if we do Python 3 only.

Here is a Google search popularity comparison for the four version control systems. This does not say everything. But git is by far the most popular. Mercurial gets some popularity because there is apparently a shoe with this name from a popular brand. I thought core Python was still using Mercurial, but the last change on hg.python.org is from 17 months ago, and CPython is developed on GitHub. So dropping Mercurial seems okay.

Maybe remove the non-git code, but try to keep the possibility of using a different VCS built in. If someone can copy our existing mercurial code and put it in a separate package that this person maintains, that would be nice. Most changes for this would be in choose.py where we choose/determine the VCS. In vcs.py we could create a dictionary VCS_SUPPORT with a mapping from the internal file/directory name (.git, .hg) to a class (Git, Mercurial) that would inherit from our BaseVersionControl class. A third party package could then add its own code to this dictionary (via a small function that we provide). That sounds like something that should not be too hard.

Theoretically, we could let our test setup register a testing VCS here, which does nothing, except some printing ('Committing with comment X', 'Creating tag Y'). That could make testing some corner cases easier. Just a thought.

After we do a few cleanups, we could release a 7.0.0a1/b1/rc1 if we think a non-final release is useful.

[woutervh]

+10 for all points. Better drop old stuff, almost nobody uses abymore, to better support newer stuff.

FYI, recently I started working on fully poetry-based projects (no setup.py/setup.cfg)

[mauritsvanrees]

I have released 7.0.0a1 to PyPI with some big refactorings. Summary:

• Only git
• Python 3.6-3.10 + PyPy3.

From my initial list above, we still have doctests and z3c.testsetup. We could still try to get rid of that. But let me close this issue, as I am happy for now.