![](https://secure.gravatar.com/avatar/d91403ac7536133c4afa2525c9d9414c.jpg?s=120&d=mm&r=g)
-----Original Message----- From: Nathaniel Smith <njs@pobox.com> Sent: Monday, July 23, 2018 10:31 PM To: Brad Warren <bmw@eff.org> Cc: distutils-sig <distutils-sig@python.org> Subject: [Distutils] Re: Packaging Advice for EFF's Certbot
Reading the problem description at the top of your document, my first thought was that this seemed like exactly what conda is designed for: a "real" package manager designed to be portable across platforms and work in isolation from the system package manager.
You should also look at Nix and Guix, which are the other systems I see people mention in this space.
I'm not an expert in conda at all -- if you want to go down this path you should probably have a chat with Anaconda and also conda-forge (which is a very impressive community-run packaging and build effort). I have some idea about some of the questions you raised though :-):
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.
How will separately distributed plugins work?
Conda has a system they call "channels" to let third-parties distribute extra conda packages, and existing systems for using/hosting/maintaining them. (Sort of similar to Ubuntu PPAs, if you know those.)
How should the user invoke Certbot (and maybe conda) if we don’t want to put another Python in the user’s PATH to avoid breaking other Python code on their system?
A little shell script to set the PATH and then exec the right binary should work. Or just setting up the #! line in your main script properly.
What should we do for systems not using 32-bit or 64-bit x86?
I know the conda folks have some stuff for ARM, though I don't know the details.
If we didn’t want to trust any binaries built by someone else or proprietary code, how much work would that be?
This is where you want to talk to conda-forge – one of the original motivations was to make a community alternative to Anaconda Inc's official packages (which were not originally open-source, and do still contain proprietary code). Nowadays everyone's on better terms, but having once rebuilt the whole distro from the ground up means they can probably share some experience with you here.
-n
-- Nathaniel J. Smith -- https://vorpus.org -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-leave@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/SFKA346UB3UQHZWNKONC63CT5VSKUTHB/