Re: Packaging Advice for EFF's Certbot

> -----Original Message-----
> From: Nathaniel Smith <[email protected]>
> Sent: Monday, July 23, 2018 10:31 PM
> To: Brad Warren <[email protected]>
> Cc: distutils-sig <[email protected]>
> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at https://mail.python.org/mm3/archives/list/distutils-
> [email protected]/message/SFKA346UB3UQHZWNKONC63CT5VSKUTHB/
--
Distutils-SIG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/F2MIDHEX2BX4TTQLWPIADPSHMKYVRQ6T/