Please test release zc.buildout==3.0.0rc3

I released zc.buildout 3.0.0rc3.

I am happy that it was in time for Plone 6.0.0a4. Thanks @mauritsvanrees !

It could have been a final 3.0.0 release if it did not need to include a workaround for distutils hack made default by recent setuptools.

I do think that the workaround included should not make any problem. Nevertheless, I would appreciate support from the community to test that release before cutting a final.

In particular, if the workaround would cause issues, it should be with buildouts that pin setuptools to other versions than the one installed in the virtualenv where buildout is installed.

I have tested it a bit more on the Plone coredev buildout, with Python 3.9.9 on macOS Catalina (10.15). All seems good. Some notes.

This is in the requirements.txt:


Those versions are also in versions.cfg.
I have tested it with several different pins in versions.cfg, pinning ever older setuptools versions:

# setuptools = 62.0.0
# setuptools = 61.3.1
# setuptools = 61.0.0
# setuptools = 60.10.0
# setuptools = 59.8.0
setuptools = 58.0.0

All went well, the buildout always finished.

What always happens in this case when the version of setuptools in pip differs from the one in the buildout versions, is that you get this during the buildout run:

  setuptools version 58.0.0;

This happens once, unless you change the version pin again. Afterwards, the bin/buildout script has setuptools in its eggs list, so it no longer uses the setuptools installed by pip.

It still gets zc.buildout from pip. If you change this version in versions.cfg, you get this message:

  zc.buildout version 3.0.0rc2;

Afterwards, the bin/buildout script is unchanged: it still uses the pip version. When you re-run buildout, you get the same "Upgraded and restarting" message again.

So the bin/buildout script can update itself permanently to use a different setuptools version, but not to use a different zc.buildout version: that is only done temporarily. In fact, when I pause execution after the "Restarting" message, this is the contents of bin/buildout:


import sys
sys.path[0:0] = [

import zc.buildout.buildout

if __name__ == '__main__':

When buildout finishes, the original contents are restored, so it again uses the buildout version from pip.

This is a bit unexpected, and maybe it could/should be fixed. But it is not necessarily good or bad. Mostly I am glad that I did not see buildout restarting itself again and again in the same run.

But the advice is clear: you should pin the same versions for zc.buildout and setuptools in versions.cfg and requirements.txt or constraints.txt.

So: for me, on this machine, it works fine.

Thanks a lot for the exploration and the detailed report !

upgrading a local installation from 6.0.0a3 to 6.0.0a4, I got this:

  zc.buildout version 3.0.0rc3,
  setuptools version 62.0.0,
  wheel version 0.37.1;
Generated script '<localpath>/plone6/test/bin/buildout'.
mr.developer: Queued '<my src egg>' for checkout.
mr.developer: Filesystem package '<my src egg>' doesn't need a checkout.
Develop: '<localpath>/plone6/test/src/<my src egg>'
  Getting section instance.
  Initializing section instance.
  Installing recipe plone.recipe.zope2instance.
  Getting distribution for 'plone.recipe.zope2instance==6.11.0'.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):

  File "<localpath>/plone6/test/lib/python3.9/site-packages/zc/buildout/", line 120, in process_url
    plinks = list(parse_links(html_page))
TypeError: wrapper_wrapper() missing 1 required positional argument: 'use_deprecated_html5lib'

I fixed it upgranding buildout to rc3 (I've upgraded pip too). As you can see, the problem happened while installing recipe plone.recipe.zope2instance but it still had to download and install all the new 6.0.0a4 eggs. After the upgrade, It started to download the new eggs:

Getting distribution for 'plone.recipe.zope2instance==6.11.0'.
Got plone.recipe.zope2instance 6.11.0.
Getting distribution for 'python-dotenv==0.19.2'.

I've also activated the venv before upgrading buildout and pip, but bin/buildout had already the right venv python and I used the venv python to upgrade buildout and pip so this should not matter.