Wow! Thanks for all the feedback everyone.
1) Can you list in the document the non-Python dependencies and what
they're used for to give people an idea?
Done! I added this to the “Certbot Background” section at the top of the document.
2) I don't know how Certbot is architected, but would it be possible
to put the "meat" of Certbot inside a Docker container (ideally
including most of the non-Python dependencies), and then have a much
lighter-weight Python application (with fewer dependencies) running
outside of Docker, and that calls the application inside the Docker
container when it needs to do stuff?
Maybe. Currently each method of performing the domain validation required to get a certificate and the support for installing the certificate in different servers is implemented by a plugin to Certbot. These plugins implement a class with a certain interface which it registers as a setuptools entry_point. At runtime, Certbot picks the class type desired by the user, creates an instance of it, and calls its methods as necessary to obtain a certificate, install it, etc. Most of these plugins make use of code in Certbot’s modules that implement common functionality to simplify plugin development.
This architecture seems like the opposite of what you’re proposing as Certbot is calling the plugin as needed rather than the other way around, but we’re certainly open to the possibility of changing things to make it easier to distribute Certbot. Are you aware of another significantly sized project that is structured in this way?
I think I'd separate out certbot installed by the package manager which is just a simple bootstrapper and the certbot installed in the virtualenv which does real work.
This is an interesting idea. By making our own .deb and .rpm packages, we can handle things like installing non-Python dependencies and adding cron jobs or systemd timers in the conventional, system specific way rather than trying to use our single certbot-auto script that tries to work everywhere. It also gives us the option to distribute this Certbot bootstrapper separately on less popular OSes with the caveat that those users will have to install dependencies and set up automating certificate renewal themselves. Thanks for the suggestion!
> How will separately distributed plugins work?
Having that layout makes plugins easy, because the paths are both standardized and relocatable (assume relative paths most of the time).
Do you know if our approach to using setuptools entry_points to find plugins will work? This is described at
https://setuptools.readthedocs.io/en/latest/setuptools.html#dynamic-discovery-of-services-and-plugins.
I work for Anaconda, and am also a core member of Conda-forge. If you have any questions or just want to talk about how conda/conda-forge may or may not meet your needs, please feel free to reach out.
Thanks a lot on this offer. I may take you up on that as I continue to dig into our options and experiment.
Not wanting to install a lot of extra software to use Certbot is certainly fair and we’d obviously prefer our packaging solution to be as lightweight as possible. Thanks for bringing this up as a consideration.
With that said, our current approaches aren’t working for us. We’re a small development team and continuing to maintain our custom certbot-auto installer which installs dependencies through your OS package manager and creates a virtual environment tucked away in /opt is a significant drain on our resources. If there’s existing tools or projects which can make this easier for us, we’d like to consider them so we can focus our efforts on Certbot and its features rather than packaging and distribution.
Our concerns with cx_freeze/pyinstaller and maintaining our own native packaging repos are listed in the Google Doc. If you have information which may help here, please share! Barring someone suggesting something we haven’t considered, maintaining our own native package repos is one of the three options we’re still considering and we haven’t heard many complaints about certbot-auto (when it works). If we go with something that requires significantly more resources though, we’ll definitely take the fact it does this into consideration and would likely offer a lighter weight (but more manual) installation process for sysadmins who prefer it.
Our main use case has been the long tail of individuals or small teams of sysadmins who maintain servers and need or want help and automation around maintaining a secure TLS configuration. Making Certbot available to anyone else who wants to use it is just icing on the cake.
However, there *are* folks that have been working on allowing
applications to be defined primarily as Python projects, and then have
the creation of wrapper native installers be a pushbutton exercise,
rather than requiring careful human handholding.
This is definitely our preferred approach to building native packages right now. To be honest, no one on my team has any experience building .debs and .rpms and we’re happy to learn what we need to if we go with this approach, but the more reliable automation around the process we can use the better.
Regardless, given the design constraints and the target audience, it's
unlikely to be possible to avoid offering a two-level solution, where
the lower platform dependent layer sets up any services and cron jobs
required, as well as establishing a Python virtual environment in
/opt, and then the bulk of certbot, as well as any installed plugins,
run in that venv (plugins would still be managed with pip, just
installed into the certbot venv rather than globally).
Outside of FPM’s support for packaging a virtual environment which Freddy Rietdijk mentioned, we really hadn’t considered this approach. I think it’s an interesting idea and could work well for us. I gave a couple more thoughts on this approach in my reply to Eli Ribble who suggested the same thing.
For actually building and publishing those platform dependent pieces,
openSUSE's Open Build Service is the most complete offering I'm aware
of: https://openbuildservice.org/ (Fedora's COPR is good for targeting
RPM based distros, and Ubuntu offer their PPA system, but OBS allows
creation of multiple respository formats).
Thanks a lot for this and the other pointers in your post Nick. It’s very helpful!