I agree that you are probably best off integrating with the system packaging system in this case.
But if you do want to deploy and app with all its dependencies in a controlled environment, conda constructor May make that easy: https://github.com/conda/constructor -CHB Sent from my iPhone On Jul 26, 2018, at 4:20 AM, Nick Coghlan <ncogh...@gmail.com> wrote: On 25 July 2018 at 12:39, Nathaniel Smith <n...@pobox.com> wrote: On Jul 24, 2018, at 4:36 AM, Nick Coghlan <ncogh...@gmail.com> wrote: 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. But it sounds like they also want to be able to install/remove/upgrade *parts* of the Python project, for their plugin support. And maybe upgrade the Python interpreter as well. Do any of these tools allow that? That's the thing that really made me think about conda. Right, that's why my suggestion was for a two layer solution (native packaging of a base platform integration layer via fpm, combined with pip for plugin management within that base environment), akin to the way Linux distro packages of Firefox and Chromium still leave the browser to do its own plugin management. That way the fpm-built native package can depend on any required system packages, as well as lay out the base virtual environment in /opt. In many ways, it's the same thing that certbot-auto is already doing, it's just replacing the current directly downloaded shell script with native Linux packages built with fpm. You can certainly do the same thing with conda instead (as per [1]), but given that the target audience for certbot includes professional Linux sysadmins, being able to integrate with the native system package manager seems to be an actively desired feature rather than an unwanted hassle. So while I'd agree conda is well worth a look as a potential helper for environment management within the /opt directory, in this particular case I don't think it's going to be a suitable replacement for offering native packages as the core update mechanism for the base platform. Cheers, Nick. [1] http://www.curiousefficiency.org/posts/2016/09/python-packaging-ecosystem.html#platform-management-or-plugin-management -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- 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/KJQNVRZJ4VTIO2IPAUVO4MSWDEK6WULI/
-- 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/VJBMVFKAH6FYYBMHXEJSBMH5G3UQHJJJ/
