Thanks Nathaniel for the mention of conda. > How will separately distributed plugins work?
Conda is based on a unix-like filesystem layout. There's a notion of a "prefix", which on linux systems is something like /usr or /usr/local. This can exist anywhere with conda, but there's a lib, bin, and include subfolder, for example. Windows is special, but much the same. Having that layout makes plugins easy, because the paths are both standardized and relocatable (assume relative paths most of the time). > 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? Conda has this "activate" functionality. It can stay off of PATH until you need it, modify it temporarily, and also set environment variables as part of activation if you need that. There are ways to make shortcuts that run executables with a conda environment activated, too. > What should we do for systems not using 32-bit or 64-bit x86? Cross compiling is quite possible, though still pretty young. We have pseudo cross compilers based on crosstool-ng right now, and extending the concept to true cross compilers would be reasonably easy (but still would require elbow grease on your end.) > If we didn’t want to trust any binaries built by someone else or proprietary code, how much work would that be? That depends very much on how much of the stack you feel like you need to rebuild. Just python? That's maybe a day's work at most, though more platforms means more time, and if you need to cross compile, that may mean more troubleshooting. The recipes are out there, you'd just need to either run them to build your own packages, or tweak them to your heart's content. Conda-forge is considered the authoritative source, and Anaconda forks their recipes and modifies them to implement different functionality, more optimization, or newer conda packaging features. The eventual goal is for Conda-forge and Anaconda to be in sync. Obviously forking further from Conda-forge or Anaconda implies more work for you. 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. HTH, Michael On Mon, Jul 23, 2018 at 9:33 PM Nathaniel Smith <n...@pobox.com> wrote: > On Mon, Jul 23, 2018 at 4:31 PM, Brad Warren <b...@eff.org> wrote: > > Hi! > > > > I work at the Electronic Frontier Foundation on Certbot which is the most > > popular end user application for obtaining and installing SSL/TLS > > certificates from Let’s Encrypt. Over the past few years, distributing > > Certbot has been one of our development team's biggest challenges and > we’re > > currently rethinking how we do so. > > > > It was suggested to me that I post to this list to see if anyone was > > interested in offering advice for how we should approach this. Of course, > > Certbot is written entirely in Python. > > > > If you’re interested, I wrote up a bit of background and what we’re > > currently thinking at > > > https://docs.google.com/document/d/1y2tc65yWnGuYsun9wsXu7ZRLCVT9eih9eu0pj7Ado60/edit?usp=sharing > . > > Feel free to reach out to me on or off list or on IRC at bmw on Freenode. > > 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 :-): > > > 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-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/SFKA346UB3UQHZWNKONC63CT5VSKUTHB/ >
-- 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/H2LKFUZLP5UPR5G74SNQXSRVZQDPIB3P/
