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 <ncoghlan@gmail.com> wrote:

On 25 July 2018 at 12:39, Nathaniel Smith <njs@pobox.com> wrote:
On Jul 24, 2018, at 4:36 AM, Nick Coghlan <ncoghlan@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 | ncoghlan@gmail.com | Brisbane, Australia
--
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/KJQNVRZJ4VTIO2IPAUVO4MSWDEK6WULI/