Brad Warren <b...@eff.org> writes: > Wow! Thanks for all the feedback everyone.
Thank you for seeking it, and for the work on making Certbot viable. > > 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> > > wrote: > > As a user of certbot, docker, conda, nix, and guix are non-starters. > > […] > > 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. Another approach is to get a good handle on the third-party dependency libraries needed for Certbot, and encourage those dependencies to be part of the OS package repositories. That way, you don't take on the huge maintenance burden of trying to keep the third-party library code *and* Certbot in good shape. Just focus on Certbot, and cheer from the sidelines as the OS distributions do the work of third party packages. Yes, that's a different set of problems (for example, keeping Certbot compatible with those versions of the libraries the OS repositories provide). But it is likely to be more manageable, for a team that wants to focus on Certbot's code base primarily. > 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. The OS distributions – the free-software ones, anyway – have communities that make it their business to do that job well. Engage with them and ask what it'll take to have Library Foo kept up to date in the OS, so you can have Certbot just declare a dependency on that. In other words, I advise: Don't look for tools to do this automatically, engage with the people who already know how to do this in each OS community. > 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. For what it's worth, I certainly concur that most people in the group you describe will thank you to not have a bundle of custom dependencies from outside the OS repository, and instead make Certbot work with (and/or be advocates to introduce) the dependencies as OS-provided library packages. > 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. For Debian, instead of becoming packaging experts yourselves, instead we ask that you make Certbot easier for *us* to package and maintain in Debian. See <URL:https://wiki.debian.org/UpstreamGuide>; other OS projects likely have similar documentation. -- \ “There's a fine line between fishing and standing on the shore | `\ looking like an idiot.” —Steven Wright | _o__) | Ben Finney -- 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/YWX6XKZLOD4IKBD5KMPSE7JEWGOYY77H/
