On 24 July 2018 at 16:10, James Bennett <ubernostrum@gmail.com> wrote:
On Mon, Jul 23, 2018 at 8:17 PM, Alex Walters <tritium-list@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.
The real question here is what use case you're targeting. Many sysadmin and devops type folks will simply never *ever* use a language-specific package manager; they'll tell you that for them, your tool or library doesn't exist unless it's accessible via the operating-system package manager (RPM, .deb, etc.). Language-specific package managers are at best for the users of the systems those people maintain, to handle application dependencies (and the sysadmin/devops people try, in their ideal world, to push for those to be replaced by custom system-package-manager repositories).
So it's likely that there's not much utility in having this be installable via the language-specific Python packaging toolchain, because your target users will refuse to take advantage of that toolchain.
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. In addition to FPM, which Freddy Rietdijk mentioned in another post, there are also projects like pyp2rpm, which backs the PyPI -> RPM feature in Fedora's COPR service: https://docs.pagure.org/copr.copr/user_documentation.html#pypi 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). 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). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia