Has anyone ever done that and can share something?
Sure, I'm developing for Plone on NixOS on a daily basis. I use containers and run buildout (via batou) inside them. My config is here:
There's a list plonePackages in options.nix; that might be the most helpful bit. Not all of them are strict requirements, there are some optional tools mixed in.
If you encounter any specific issues let me know, maybe I recognise something I've fixed before.
Edit: Not sure how familiar you are with NixOS, but maybe I should mention that for the dev packages you need to take care of C_INCLUDE_PATH and LIBRARY_PATH, see base.nix.
1 Like
I use the same approach as @reinhardt (because of batou). It's mainly just a convenient way to manage containers for Plone projects declaratively, providing any system dependencies and services you may need.
I know @datakurre has done lots of nice things to take greater advantage of nix. For example, there's a modified version of buildout in nixpkgs ("buildout_nix") that allows buildout to re-use python packages from the store. You could use that to bootstrap your buildout with with pre-built python c-modules, such as lxml. There are also tools to generate nix expressions for python packages, although I don't know which is the most appropriate at the moment. You could use these to define a shell.nix will all the dependencies you need for a project and then use buildout_nix to generate the configuration and manage development versions as normal.
There are quite a few people who are familiar with Plone in the NixOS community, so it would pay to ask on the IRC channel and on discourse too, if you haven't already.
1 Like
Thanks @reinhardt and cillian,
it's very interesting. Thanks to cillian (it appears that i cannot mention more than two people as I'm a new user) suggestion I found also @datakurre repo with plone setup and configuration which takes a completely different approach. From what I see @reinhardt uses NixOS containers to complement Plone with a pool of applications and system services frequently used together: nginx, memcache, poppler tools, etc. In this solution the environment is prepared with NixOS compatibility and Plone is installed with the usual tools.
In @datakurre's solution instead Plone is installed using a tool that converts pip's requirements.txt dependency files to an equivalent requirements.nix containing Nix derivations. Plone is then configured using a Nix expression, without using buildout (from what I was able to see without trying it out)
I think I'll try with @datakurre's approach first, as I want also to get rid of buildout, which I don't trust as a long-term instance management tool. I installed Plone since its first release and my experience with it is unsatisfactory: while it's a good tool to quickly set up an instance in the long run I don't want to manage it with a tool that re-renders the configuration every time I add a python package to the environment.
Anyway, thank you all for your valuable suggestions !
1 Like
Excellent! I think @datakurre's approach is optimal. You can really benefit from nix: binary deployments, rollbacks, easily reproducible, etc. Of course, you can then also use NixOS for any additional services you want to deploy and you can manage all your services with systemd rather than supervisor. You can simplify a lot of things, reduce the complexity of your stack and it makes everything more robust and easier to reason about.
It's worth mentioning that NixOS doesn't manage state, but you might also be interested in Dysnomia for that: https://www.youtube.com/watch?v=7xDVTflSrdU
Best of luck!
1 Like
I've started coding "site" deployments as types in NixOS modules, managing all the relevant dependencies (service dependencies too) with Nix configuration modules that produce containers: as of now I have only a wagtail site type, but I would like to add a Plone type as well.
It took me some time to learn Nix and NixOS modules to the point where i learned that options submodules can be functions too and can be used in conjunction with extensible option types.
Dysnomia and Disnix are very interesting projects and a proof of what can be achieved using mcedit as editor (sorry Sander, I couldn't resist 
) and it's certainly something I'll experiment with in the future. For now I'll manage state migration manually.
For now one of the most (somewhat) unexpected advantages is the relatively easy testing of deployments that NixOS allows: it's pretty amazing.
1 Like
ZServer also has optional sd_notify support baked in.
2 Likes
I updated https://github.com/datakurre/plone-nix/ to for the latest Plone 5.1 and the latest NixOS 18.09 version of nixpkgs. And this time I pinned everything so it should not get broken anymore.
I believe it still requires patched version of z3c.autoinclude (I did not try the latest version yet) and because it does not use buildout, it requires the scripts from plone.recipe.zope2instance that I tried to put into plonecli, but are still looking for final home (presumable plonectl when that happens). Of course, all these are included in the example. As well as zope.conf nix-generator.
The disclaimer is that we don't yet use these in production by ourselves.
2 Likes
I updated https://github.com/datakurre/plone-nix with my current approach on packaging Plone and Volto with Nix.
Probably quite a mess for anyone outside Nix-bubble, but still... it is Nix-composable with Nix-generated configuration, does not require buildout (beyond updating the basic Plone requirements.txt), but does use Twisted ZServer instead of WSGI.
Fun fact is that in the resulting Docker image, Volto SSR server and Plone are quite equal in their sizes. (Obviously this can be also used without docker.)
1 Like
I've done some work as well and I'm now able to produce Plone Nix environments for Plone 5.2.2 and 5.2.3-pending. See https://gitlab.com/metapensiero/plone-nix
2 Likes