Wow! Thanks for all the feedback everyone.
> On Jul 23, 2018, at 6:52 PM, Chris Jerdonek <chris.jerdo...@gmail.com> wrote:
>
> 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?
> On Jul 23, 2018, at 7:04 PM, Eli Ribble via Distutils-SIG
> <distutils-sig@python.org> wrote:
>
> 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!
> On Jul 23, 2018, at 7:54 PM, Michael Sarahan <msara...@anaconda.com> wrote:
>
> > 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
<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.
> On Jul 23, 2018, at 11:10 PM, James Bennett <ubernost...@gmail.com> wrote:
>
> On Mon, Jul 23, 2018 at 8:17 PM, Alex Walters <tritium-l...@sdamon.com
> <mailto:tritium-l...@sdamon.com>> wrote:
> As a user of certbot, docker, conda, nix, and guix are non-starters. I'm not
> depending on those tools for my production server (and while docker may be a
> dependency for some people, that is hardly universal). Adding heavyweight
> technical dependencies are problematic if your goal is to get everyone using
> your software. You're better off with cx_freeze or pyinstaller binaries
> downloaded from a website or a PPA-like-system to add to system package
> managers, which are not perfect solutions either.
>
> I would emphasize this point.
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.
> The real question here is what use case you're targeting.
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.
> On Jul 24, 2018, at 4:36 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> 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!
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/E364VEIRYBK32CA2BBEUQYKKZVWWVR3Q/
