I made the mistake of adding release-5.2.2-versions.cfg and requirements.txt to that base_skeleton directory myself... Will remove them.
This is really frustrating. I've been testing the 5.2.2 unified installer using the master branch today.
@tobiasherp when you updated it to install Python 3.8.5, I think you missed some spots where 3.6 was assumed. I'm testing on a Mac.
$ ./install.sh --build-python="3" standalone
Unable to find libssl or openssl/ssl.h. libssl and its development headers are required for Plone. Please install your platform's openssl-dev package and try again. (If your system is using an SSL other than openssl or is putting the libraries/headers in an unconventional place, you may need to set CFLAGS/CPPFLAGS/LDFLAGS environment variables to specify the locations.) If you want to install Plone without SSL support, specify --without-ssl on the installer command line.
$ export LDFLAGS="-L/usr/local/opt/libxml2/lib -L/usr/local/opt/libxslt/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/openssl/lib"
$ export CPPFLAGS="-I/usr/local/opt/libxml2/include -I/usr/local/opt/libxslt/include -I/usr/local/opt/zlib/include -I/usr/local/opt/openssl/include"
$ ./install.sh --build-python="3" standalone
Rootless install method chosen. Will install for use by system user kimadmin
Detailed installation log being written to /Users/kimadmin/Downloads/Plone-5.2.2-UnifiedInstaller/install.log
Installing Plone 5.2.2 at /Users/kimadmin/Plone
Downloading Python source from https://www.python.org/ftp/python/3.8.5/Python-3.8.5.tgz
Downloading Python-3.8.5.tgz with curl
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 23.0M 100 23.0M 0 0 11.9M 0 0:00:01 0:00:01 --:--:-- 11.9M
Installing Python-3.8.5. This takes a while...
./configure --disable-toolbox-glue --disable-ipv6 --disable-framework --prefix=/Users/kimadmin/Plone/Python-3.6 ...
make install ...
Failed: This Python does not have ssl support.
If you want to disable this check, add --without-ssl=yes
to the command line.
***Aborting*** The built Python does not meet the requirements for Zope/Plone. Check messages and the install.log to find out what went wrong. See the "Built Python does not meet requirements" section of README.txt for more information about this error.
If I try the --build-python flag with the 5.2.1 installer, which builds Python 3.6.9:
$ export LDFLAGS="-L/usr/local/opt/libxml2/lib -L/usr/local/opt/libxslt/lib -L/usr/local/opt/zlib/lib -L/usr/local/opt/openssl/lib"
$ export CPPFLAGS="-I/usr/local/opt/libxml2/include -I/usr/local/opt/libxslt/include -I/usr/local/opt/zlib/include -I/usr/local/opt/openssl/include"
$ ./install.sh --build-python="3" standalone
Rootless install method chosen. Will install for use by system user kimadmin
Detailed installation log being written to /Users/kimadmin/Downloads/Plone-5.2.1-UnifiedInstaller-r3 2/install.log
Installing Plone 5.2.1 at /Users/kimadmin/Plone
Downloading Python source from https://www.python.org/ftp/python/3.6.9/Python-3.6.9.tgz
Downloading Python-3.6.9.tgz with curl
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 21.9M 100 21.9M 0 0 12.0M 0 0:00:01 0:00:01 --:--:-- 12.0M
Installing Python-3.6.9. This takes a while...
./configure --disable-toolbox-glue --disable-ipv6 --disable-framework --prefix=/Users/kimadmin/Plone/Python-3.6 ...
make install ...
Python build looks OK.
Creating Python virtual environment.
Using base prefix '/Users/kimadmin/Plone/Python-3.6'
New python executable in /Users/kimadmin/Plone/zinstance/bin/python3
Also creating executable in /Users/kimadmin/Plone/zinstance/bin/python
Installing setuptools, pip, wheel...
done.
Installing Python requirements in virtual environment.
Copying Plone-docs
Copying buildout skeleton
Building Zope/Plone; this takes a while...
So... I am pretty annoyed at having wasted hours trying to get back to a working state from which I can create WORKING AND TESTED installers for 5.2.2, 5.1.7, and 4.3.19.
I refuse to waste any more time on this or going forward until and unless others who merge into master have actually tested and spent time to understand what they are modifying.
I would also appreciate people adding change log entries and testing thoroughly before merging to master.
I seriously give up. I quit.
I'll try to set up a GH action that build the installer and use the installer artifact on the 3 provided platforms to install Plone. Without some automation here were lost.
Here we go - still WIP, but with automation! macos and linux is tested, windows never was and so is not (I started here, but I fear a VM is needed to develop the tests first.
Best of all, it seems to work.
I someone has an clue why the install test are failing on macos wth Py 3.7 please tell me https://github.com/plone/Installers-UnifiedInstaller/runs/11736292
All other combinations linux/mac/2.7,3.6-3.8 are working.
Ok; seems the compilation of different Python interpreter versions is more complicated than I thought. Sorry.
In my case, I had stumbled into the Python3: ImportError: No module named '_ctypes' when using Value from module multiprocessing problem; after
sudo yum install libffi-devel
(on my CentOS box), the newly built Python 3.8.5 was fine.
I'm afraid I don't have the expertise about resolving such issues in a generic way.
Do we have a contribution documentation anywhere?
I am even not sure if we need to compile Python in the installer. IMO the whole installer does too much,
Today, on Windows on installs Python before, on Linux there are packages OR one can use pyenv and on Macos theres the brew system.
We should focus on whats come after Python. Even here we have improvement potential.
Furthermore I would like to see our existing toolchain to be used to install Plone, namely this is PloneCLI.
That way we have also a lower burden to make the installer do all the same things as PloneCLI does. PloneCLI does the same: it generates a buildout, runs it, start Plone. It depends on bobtemplates.plone and so on the provided templates.
Polishing all the chain down would help the overall Plone experience to use one tested way to install. Targeting for a multiple use like first time install and trial and then development in one would also lower the barrier for new users. IMO the installer should not cover production systems, but even this could be possible given we have the right templates.
Thus said PloneCLI (spec.bobtemplates.plone) could also be modified to target different ways of installation: A feature we need for Plone 6.0 where we plan to ask the User which to install, Plone Core or Plone Volto.
I am open to discuss this for Plone 6 and also have @tisto @sneridagh (Volto), @MrTango (PloneCLI) and the installer team and everyone interested (@fredvd?) in a call. Since this is some work - probably less than using our old installer - this needs planning.
What do you think?
I am even not sure if we need to compile Python in the installer.
I'd second that. This feature is really a leftover from the days when popular platforms did not have adequate Pythons available -- either built-in or by package. Those days are mostly gone, and deficiencies (I'm looking at you CentOS) could be best remedied by good documentation.
I'm not so sure about this. Over the years, my experience was that the UI was most used by the least experienced. The main target was never developers -- who can usually figure out how to do it themselves -- but rather inexperienced integrators. Those are the people unlikely to understand subtleties like making the production instances operate under a different user id than buildout.
But even this is possible with PloneCLI, we "just" need a template for this.
People are shooting themselves in the feet with the Universal Installer and our Installation instructions. Just see this thread from yesterday and today: Working Installation Documentation - #7 by zopyx
I posted the links to the installation instructions in docs.plone.org in that thread partly as an experiment. In a slack discussion last week with other community members one remark was 'but we do have installation instructions' . Yes we do, but they're confusing to people.
Jens' response there was the most direct 'solution available at the moment if the platform is not Windows: use the system Python, install dependencies, run minimal buildout, start.
But even Windows is getting there with WSL(2) to support installation from source in a unixy-container.
Over the years, my experience was that the UI was most used by the least experienced. The main target was never developers -- who can usually figure out how to do it themselves -- but rather inexperienced integrators.
Let's talk about the goals and the target group:
We 'the community' need to have a 'political incorrect' discussion about what we want to achieve with Plone in 2020 and beyond. Do we still want to put Plone in the hands of as many people as possible to democratise publishing on the Internet and intranets by giving them a 'works out of the box' Plone Application? Is that still necessary and if people think so: can we find sponsors for that goal?
I'm aware it sounds very elitist and entitled coming from me and other developers/sysadmins/integrators, but maybe we should protect inexperienced integrators from installing Plone and seemingly getting it up and running as a production environment. When in fact it was sheer luck and/or they have no clue what they are doing. And cannot solve basic issues when something or anything goes wrong on that production system. Like restoring the backup that wasn't made.
I'd love to give everybody who wants to their own 'Plone in a black box' with 4 buttons (start, stop, backup, restore) that runs on any possible platform, but we would need significantly more resources for that to still wrap Plone as an 'end user' product.
Also the technical bar has been raised significantly in web/frontend development on knowledge on how to run command in a terminal. 10-12 years ago a UX designer or frontender could still be proud to say they were a brilliant Photoshop wizard and therefore didn't know how to descend into a dark terminal. It's 2020 and you can't do much modern frontend development without a bash/zsh/whatever prompt.
Maybe we should demand at least minimal terminal fluency from our target group to set up a Plone site locally from source and accept that the learning curve involved serves a purpose and is not 'hostile' towards power users anymore in 2020.
There's a really good acceptable alternative nowadays if you can't install a server/service yourself or don't want to spend time tinkering/learning on it. SAAS.
2 Likes
Plone installation and Plone administration clearly does not belong in the hands over everyone.
Administrator likely nowadays expect stuff to work in the cloud, through Docker, through Kubernetes.
Plone n00bs need something reliable to work out-of-the-box on their local system (Windows, Mac, Linux) e.g. for testing and evaluation...also Docker image could/can help here.
However the pain with Docker and Plone starts with building Docker image for Plone, debugging Plone docker images and updating Plone Docker images...in the need we replace the standard installation pain with Docker pain.