Please test buildout 3

Yesterday, buildout 3.0.0b1 has been released!

@gotcha has put enormous efforts in the development of the upcoming version 3, which is now using pip.install under its hood instead of setuptools.easy_install.

While @icemac today released a new version 2.13.4 which pins setuptools, as the latter has removed support for easy_install, it is quite possible that this is the final version of the 2.13 line.

So, please take a couple of minutes and test your application with the pre-release of buildout version 3 and report any issues to our issue tracker.

Thank you!

2 Likes

Updated union.cms just now to buildout 3: Did not have any problems.

1 Like

Do you use batou for union.cms? I have some problems on my dev machine to get batou / especially batou scm to work with the latest buildout pre-release, but this maybe be entirely a local problem.

I created can't get it work with the latest buildout 3 pre-release · Issue #11 · gocept/batou_scm · GitHub

No, just buildout.

1 Like

Thanks for your feedback.

I figured out it is a problem in batou itself.

Plone 6.0 coredev now uses buildout 3 beta 2! Thank you @gotcha and all involved!

3 Likes

Tested it on pendect.com and it worked like charm.
Thanks, @gotcha and all Zope community

1 Like

It is great to hear that you all had success with 3.0.0b2. And thanks for the thanks :slight_smile:

On our way to a final release, it would be great if you could contact people outside the Plone community that you know still use zc.buildout to ask them to also test the latest beta.

I already spoke to some of them, but the more we people we find the less chances that bugs like the one @jensens found in 3.0.0b1 remain unseen.

Plone is probably the hell of an use case for buildout :smiley: but sure, more testing is always good.

The main source of issues I am afraid of is valid eggs built with conventions I did not think of. Most of our Plone packages follow common patterns. This is why I hope that with more diverse sources of packages, the chances of detecting patterns I missed are greater.

Just updated my coredev 6 buildout and ran into this error

No .dist-info directory after successful pip install of /var/folders/q9/g4v63j9s0h122t997shqn3n80000gn/T/tmpl_j44joyget_dist/Pillow-6.2.2.tar.gz
While:
  Installing instance.
  Getting distribution for 'Pillow==6.2.2'.

Successfully ran that buildout before ... full traceback ❯ buildout -Nmr.developer: Queued 'Plone' for checkout.mr.developer: Queued - Pastebin.com

Could that be related to buildout 3?

OSX 11.2.3 (Intel), fresh pyenv, new requirements installed, clean eggs dir

@agitator

I cannot reproduce the problem on my Ubuntu 18.04 laptop with zc.buildout 3.0.0b2.

When I look at your build log, I think this is the problem..

  The headers or library files could not be found for zlib,
  a required dependency when compiling Pillow from source.

buildout version 3 now uses pip as the install backend, and pip usually loads a wheel (though I do not know how this relates to the eggs ..).

As at your system zlib is not downloaded, but compiling is starting, I can only guess, that ...

  • either there is no pre-built package available for your system
  • you have a too old pip version

Can you do a pip --version?

zc.buildout used easy_install as a backend, so the pip version did not matter for zc.buildout 2.13 line.

P.S.: Which Python version do you run? -> 3.8.7 when I have a look at your log

P.P.S: Which version of setuptools are you using? This is also a common source of problems.

I tested here on my local system. Coredev buildout Plone 6, pyenv, Python 3.8.7, Ubuntu 20.04. All runs very fine.

1 Like

Made a fresh virtualenv (plone6-py387-buildout3) for 3.8.7 with pyenv, then pip install requirements

setuptools==54.0.0
zc.buildout==3.0.0b2
pip==21.0.1

pip and setuptools show exactly those versions

Can't remember the header files being a problem so far although brew on installing Zlib says

zlib is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

I could do an pip install Pillow==6.2.2 without a problem and looking at the traceback buildout seems to get that binary as well .../tmpbfflftx3get_dist/Pillow-6.2.2.tar.gz?

Not sure what I should make of No .dist-info directory after successful pip install of /var/folders/q9/g4v63j9s0h122t997shqn3n80000gn/T/tmpbfflftx3get_dist/Pillow-6.2.2.tar.gz

  1. When I run the buildout below on my Mac, it fetches a wheel rather than a .tgz. Would be worth to debug why you get a .tgz on your machine

    [buildout]
    parts=pil

    [pil]
    recipe=zc.recipe.egg
    eggs=Pillow

    [versions]
    Pillow=6.2.2

  2. Can you check the content of what has been installed by buildout when installing Pillow tgz ?
    buildout 3.0 relies on metadata found in dist-info directories. There might be other directories that needs to be searched.

  3. We should move this discussion to buildout issues on github. @agitator Can you file what you have found ?

1 Like

Thank you for working on this @gotcha! That's a very important leap forward! You rock!!!

1 Like

Thanks for the great work :+1:

Does anyone know if it will be possible to use Buildout 3 together with a private Pypi server (e.g. devpi + Basic Auth + .pypirc)? In my local tests with Buildout 3, that didn't seem to be possible. With Buildout 2 this worked like a charm.

@mliebischer I think it would be a good idea to file an issue over at Issues · buildout/buildout · GitHub

I see no issue in that specific scenario, we're using pypiserver (pypiserver · PyPI) behind Apache with mod_wsgi.