Is anyone using Plone without using zc.buildout? You can install Plone packages in a virtualenv using pip, but then you still need a few configuration files and probably extra scripts.
Or has anyone replaced specific recipes by more general purpose recipes or other tools? For instance, there are various recipes that install Python packages or Unix tools plus a configuration file and script.
collective.recipe.supervisor: you could install the Python supervisor package (with buildout or pip) and manually or with a template prepare a supervisord.conf configuration file. And create simple supervisord and supervisorctl scripts that use the configuration.
plone.recipe.varnish: you could instead use zc.recipe.cmmi to install varnish, and again use a template (plone.recipe.template) to create the configuration.
collective.recipe.backup: this would be hard to replace, because the resulting bin/backup script calls actual code from the recipe, especially for handling the blobstorage.
You could probably use Ansible for some of this. But that seems more geared towards deploying on servers, and not for creating a local Plone Site. And the Plone Site part of the Plone Ansible Playbook still uses buildout.
So: is buildout still your standard to create Plone instances for development and production? Or are you moving towards other solutions?
To answer my own questions: At my employer Zest, we use buildout for everything, and we use the recipes from my examples above. We use Fabric files to assist in deploying to the server. We host several Plone Sites per server.
Background for this question: I am working on a tool that is very much like buildout, including extensions and recipes, but as big difference: using pip for installing packages. To quote Jim Fulton in 2017: "When we started buildout, it wasn't a goal to solve packaging problems. The goal was to automate creation of software configurations. I only ended up writing as much packaging code as I did because setuptools behavior didn't meet my requirements for repeatability. I don't think that packaging is where buildout should be mainly providing value."
At kitconcept we use buildout only to build Plone itself these days. We do everything else with Ansible. If a pip-installable Plone would become a thing, I guess we would go with that.
I'm always let down by anything other than buildout when doing python stuff. Don't kill it, please
I've tried
pip+virtualenv: doesn't cleanup when requirements.txt changes.
pipenv: doesn't prefer final releases when allowing a pre-release; ie need black, get all the alphas.
poetry: doesn't allow for multiple scripts with different eggs; ie bin/manage.py and bin/manage_debug.py - where the latter has django_toolbar as well.
Version pinning via extending another buildout file is really nice. pip constraint just isn't.
I've got the feeling that you'll end up building a lot more additional tooling to fix issues that you won't have when you're using buildout.
Have said this, I don't think it is a good idea to install additional software like varnish, nginx, etc with buildout as part of your project. I think that's part of your SCM layer - ie Ansible, Salt and the likes.
No killing will be done. I quite like buildout, despite occasional troubles.
Yes, that would be a downside of a future new tool I am working on. On the other hand, you could then do a quick pip install django_toolbar (manually, or properly with the tool) and bin/manage.py would have the extra package.
I love buildout and haven't yet found a complete replacement for what it does very well, which is configuration management.
I no longer do any Plone work, but I still use buildout in order to create different configuration profiles (dev, staging, production).
Not only that, but I've also set up a buildout environment for developing on the Prosody XMPP server and its add-on modules (all of which are written in Lua, not Python!). It's so much nicer to let buildout do these things for me instead of having to do them by hand.
I quite like buildout, despite occasional troubles.