Deploying and Operating Plone on WSGI tutorial fails in buildout

I am trying to follow the tutorial found here: Deploying and Operating Plone on WSGI โ€” Plone Training 2022 documentation

It fails during buildout:

$ buildout -c basic.cfg
Upgraded:
  zc.buildout version 2.13.4,
  setuptools version 42.0.2;
restarting.
Upgraded:
  zc.buildout version 2.13.4,
  setuptools version 42.0.2;
restarting.

It just keeps repeating those same 4 lines.

I've tried commenting out the mr.developer and auto-checkout lines to no avail.

The repeatedly restarting of buildout while trying to upgrade zc.buildout or setuptools indicates there is already a different version of zc.buildout or setuptools installed in your Python environment, or more precise the virtualenv. Buildout tries to install another version of what already is in the python environment, this fails, buildout restarts and then finds the same mismatching versions, tries again, etc. etc.

to check: activate the virtualenv and check what bin/pip list outputs for zc.buildout and for setuptools modules. These versions should match the pinned versions for these modules in the buildout he basic.cfg and other 'extended' cfg files from basic.cfg.

The versions listed by bin/pip were probably taken from the requirements.txt file when you installed ('bootstrapped') the modules in the virtual env when doing

bin/pip install -r requirements.txt

Just after creating and activating the virtualenv. Make sure that the versions in the requirements.txt match those in buildout, rerun the above command and then run bin/buildout again. Now buildout should continue.

2 Likes

Thanks for the quick reply.
What I did before I saw your reply was to try again from scratch.
My distro does not have a python 3.7. So I'm making due with python 3.6.
We also don't use vagrant. It appears as if any dev instance will do.
I got past my initial issue.
I copied my original zinstance so I had a fresh dev instance to work with. (Note - I am working with Plone 5.1.7, and altered base.cfg to match)
I then manually installed the specific versions of setuptools and zc.buildout it wants.

Now, the buildout fails after doing a bunch of stuff.

Getting distribution for 'zodbpickle==0.7.0'.
WARNING: The easy_install command is deprecated and will be removed in a future version.
warning: no previously-included files matching '*.dll' found anywhere in distribution
warning: no previously-included files matching '*.pyc' found anywhere in distribution
warning: no previously-included files matching '*.pyo' found anywhere in distribution
warning: no previously-included files matching '*.so' found anywhere in distribution
In file included from /usr/include/python3.6m/Python.h:8:0,
                 from src/zodbpickle/_pickle_33.c:1:
/usr/include/python3.6m/pyconfig.h:4:25: fatal error: pyconfig-32.h: No such file or directory
 #include "pyconfig-32.h"
                         ^
compilation terminated.

I tried pip install pyconfig but that did not change the error.

Searching the internet, it appears that that header file comes from the 32-bit version of the python package.
Is 32-bit python truly necessary for Zope/Plone?

First som background: The challenge here is that you are working from one of several 'individual' trainings that are hosted on training.plone.org. The global table of contents nicely has '2022' in the header, but I think this particular WSGI training/tutorial is already 2 or 3 years old and the training itself wasn't run on the last two Plone Conferences IIRC, so its content has not been updated/validated.

You missed the reference on this page 1. Setup a box for the training โ€“ Deploying and Operating Plone on WSGI โ€” Plone Training 2022 documentation to the generic server setup instructions in another training:

That training material has been updated recently, so it now mentions python3.9, but you are missing the python3.7-dev header files on your linux system. And probably quire a few other OS level packages that Plone needs to be present to succesfully install all needed Python modules.

I'm referring to these instructions:

sudo apt-get update
sudo apt-get -y upgrade

sudo apt-get install python3.9-dev python3.9-tk python3.9-venv build-essential libssl-dev libxml2-dev libxslt1-dev libbz2-dev libjpeg62-dev
sudo apt-get install libreadline-dev wv poppler-utils
sudo apt-get install git

I've tried git branch and git tag within the wsgitraining repo. Both don't list anything helpful for checking out an older version of the training - which apparently is what I need.

I guess it's down to stumbling through WSGI myself. The closest thing to an old tutorial I found is when the devs first got WSGI working with Zope.

Hmm. Sorry, Maybe if you have done that it really is the whole 32/64 bit shizzle that happened 5-8 years ago where linux distributions tried to support both system types, your output does list the main python header files that python3.6-dev should install:

In file included from /usr/include/python3.6m/Python.h:8:0,
                 from src/zodbpickle/_pickle_33.c:1:
/usr/include/python3.6m/pyconfig.h:4:25:
1 Like

Your problem is very unlikely to be related to wsgi. The issue is that a number of Python packages from which Plone is built:

  • are partly written in C for speed optimisations and need to be compiled.
  • and/or need lower level (system) libraries present on the server and then the setup tries to install a 'binding' python-packageso that Python can use functions from those libraries.

You won't find any information on solving these issues for deprecated software release combinations in the provided training material. It's a hairy edge case on older OS releases and older software packages.

Plone 5.1 is no longer supported, Python 3.6 is also no longer supported. And your server OS is probably also out of support if it doesn't have anything higher than Python 3.6 . You are in the 'here be dragons' zone if you don't have previous experience with these situations. :frowning:

What I was doing when I found the tutorial was searching for a buildout config to turn WSGI on. The old documentation does not seem to say exactly how to do that.
The infuriating thing is that the buildout in the tutorial uses mr.developer and other DEV stuff that would never make it into production. The tutorial relies on downloading things out of the wsgitraining container, so I still don't know what a proper buildout.cfg is for turning on WSGI.
I'm fine without an actual running demo as long as it has relevant configs in it. This tutorial does not.
Why would any tutorial be built such that it relies on downloaded configs? A baseline example config should be included at the very minimum - then Plone could still do their mr.developer/download thing and the tutorial could be useful for someone who is not / cannot be running the very latest bleeding edge Plone.

The training is from 2019 PloneConf.

I don't know the full history of it. I would assume that, at the time, this training was intended to help in the transition to WSGI and Waitress from ZServer by default in the recently released Plone 5.2. Since 2019 there have been many changes to getting started.

I'm not sure what you really need, though. You get WSGI and Waitress out of the box ever since Plone 5.2.

1 Like

Thanks Steve.
I was attempting to not have to jump all the way to Zope 4. I was looking for actual documentation on WSGI in Zope 2.13.
But, collating all the sparse info I've been able to find, WSGI on Zope 2.13 is kludgy to begin with.
I think what I'm going to recommend is, assuming I can get all the web plumbing to work properly with the WSGI-ified Zope 4, is to then make a slow and painful 3-step migration up to Plone 5.2.1. Then possibly one more step to Plone 5.2.6

What is it exactly that you want to achieve/ have to do?

'Our' challenge with giving support to other users in the community is that we do our best to respond to questions that are sometimes already 4-5 levels deep into a problem solving direction where there might already be a misunderstanding or different possible solution on level 1 or 2. What is the overal context before you got stuck on a zc.buildout version pinning issue?

What Plone version are you migrating from? To which version do you want to migrate? For what use case do you now need wsgi that wasn't necessary first on a 'pre' wsgi (Zserver) setup? Why do you first want to migrate to Plone 5.2.1 and not directly to 5.2.6, at least saving yourself one step. Why do you need to perform a 'painful' 3-step migration?

We're running Zope 2.10.6. It was installed via the Plone 3.3 installer. But we run Zope, not Plone. I believe the original Zope implementation was 2.6.
ZServer does not process environment from new required modules in our Apache properly. I believe WSGI will based on testing I've done without starting Zope.
What's going to be painful is the fact that we have 4 old-Zope Products which we heavily use, most of which were dead even before 2.10.

I'm a new resource brought into this legacy product. I've been trying to learn Zope/Plone as well as how this legacy app uses Zope as fast as I can to be able to make well informed recommendations on how to proceed. There is a replacement app being developed, but in the meantime, we need to keep this legacy beast running - and incorporate new tech requirements into it.

I find it distressing that it is extremely hard, if not impossible, to find the full documentation on how Zope used to work. There are hordes of dead links on the old-Zope, Zope, and Plone websites to documentation and tutorials, some of which are only a version or two old. I'm not surprised about the old-Zope website, but the Zope website is actively maintained.

The reason I am looking at Plone 5.2.1 is because it utilizes Zope 4.1. Starting in 5.2.2, the Zope version jumps to 4.5. Given the age of the legacy app I don't want to make too large a leap at once - unless I can be assured the Zope 4.1 to 4.5 difference is not as major as the version number indicates. Keep in mind that we do not run Plone. Our app is very much a Zope app.

As this is your main issue at the moment, what do you mean with 'Zserver does not process environment'? Are you describing HTTP headers on the incoming http request?

I'd stay away a far as I can from trying to upgrade the whole framework under a 10-15 year old legacy web application to 3 higher major versions because of an bug, certainly when a replacement app is already under development.

And if you do want to test if upgrading Zope itself will 'black box' fix your issue with minimal risk of breaking other components in the legacy servser, upgrade to Zope2 2.13.30 max. (Zope2 ยท PyPI) which is the latest in the Zope2 series.