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?
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).
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.
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.
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:
buildout, for all its difficulties in bootstrapping, has solved some pretty tough problems in pretty good ways
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.