GSoC 2018 Ideas: Bulet-proof bootstrap Plone process

Plone Support
, ,
1

This is one post in a series to begin focused discussion about ideas that came out of our 2018 GSoC Brainstorm.

Please use this post as a place to begin to discuss this idea more in depth.

This topic was suggested by @hvelarde, who suggests that a member of the installers team might be a good mentor.

The description:

"We have a problem with the current bootstrap process as can be seen here we need to find a better way of bootstraping our projects."

This is a vital topic for adoption, let's see if we can drum up some support here for it!

2

AFAIK, Plone is pip ready (I seemed to need only pip branch of z3c.autoinclude to make it run). Not much is needed for plonecli to make it able to create Plone project skeletons and run instances instead of plone.recipe.zope2instance by buildout.

@hvelarde would buildout-free Plone match your goals on this?

3

not sure that we want to get rid of buildout; can you elaborate?

4

Wasn’t your example problem mostly about buildout? Maybe I didn’t fully understand your idea.

With ”more robust” I was thinking about less tools and simpler setup. Minimal Plone that I tried, required: requirements.txt, zope.conf, a directory with ./etc/site.zcml and a writable directory for storages, logs and lock files. That almost in par with the other frameworks (only missing option for full path of site.zcml).

5

I was more focused just on the bootstraping process, what you're managing with requirements.txt.

I've been following the discussion but I'm against using that until it has been declared the standard way of bootstraping buildout and not just another way of doing it.

probably you have better ideas on the rest of the stack.

if not, this seems not to be a good candidate for a GSoC project.

6

I am sure we want to offer a standard Python hosting story. Buildout puts many people off.

I am also sure I'll stay on buildout myself for a lot of stuff.

Can you split off a thread or a blog post for an example on how to roll that way?

7

Please make sure the major reasons buildout is painful are solved before suggesting something new.

  1. Dependency hell.
  2. adding new plugins or your own code, without risking dependency hell.
  3. dependency hell causing existing running code to not run after a restart

I'm not sure pip solves these does it?

8

Dependency hell is not the biggest problem with proper pinned packages.

Buildout can not just replaced with PIP for obvious reasons: configuration management, instance(s) setup are a key and very important functionality of buildout and its recipes.

The major pain in the *** with buildout is the bootstrapping phase. In almost every project nowadays I have to fiddle with zc.buildout and setuptools versions - even in old projects with nailed down version pins.

PIP alone does not solve anything here, absolutely nothing.

-aj

9

This facet of the problem space is not unsolved in properly deployed apps out there. Some use requirements-scope.txt.in files for defining top level dependencies and now there is the pipfile project as well.

This is what I'm trying to communicate - the currently popular Python hosting story has the configuration jammed in via the environment. Making Plone zeo servers and clients pip-installable forces us to figure that stuff out / opens the venue up for the adventurous.

This is IMO nice as it does not break any existing way of doing things.

10

Thanks for the link to the pipfile project @Rotonen. I'd been aware of it, but hadn't yet looked at the specification in depth. A solid implementation of what they are discussing there would go a long way toward solving the problems pip has with the management of complex systems over time.

As I step out into the world and interact with more and more build systems, I am quickly coming to two not entirely compatible conclusions:

  1. buildout, for all its difficulties in bootstrapping, has solved some pretty tough problems in pretty good ways
  2. going with a system that does not stay close to what the larger Python community is doing for packaging and installation is a road to madness. Micro-community means slow progress, and losing touch with what is current.

I'm not sure how to resolve those two observations. I think they're both true, but they do contradict each-other.

11