[Distutils] Idea: allow PyPI projects to link to DockerHub container images

[Ionel Cristian Mărieș]

Wouldn't this be a good time to discuss other types of URLs?

Eg:

* Documentation
* CI status (in the many different flavors)
* Issue tracker
* Forum/mailing list
* Support place

After all, there's nothing special about docker images - every project is
going to have a different special thing at some URL.


Thanks,
-- Ionel Cristian Mărieș, blog.ionelmc.ro

On Sun, Feb 1, 2015 at 2:43 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> One of the recurring problems folks mention here is how to deal with
> the complexities of handling Linux ABI compatibility issues.
>
> That's a genuinely hard problem, and not one that *anyone* has solved
> well - it's one of the reasons being an independent software vendor
> for Linux in general (rather than just certifying with the major
> commercial distros) is a pain. When folks do it, they tend to take the
> "bundle everything you need and drop it somewhere in /opt" approach
> which (quite rightly) makes professional system administrators very
> unhappy.
>
> On the distro side, this is one of the big factors driving the
> popularity of the "bundle all the things" container image model: it
> does the bundling in such a way that it's amenable to programmatic
> introspection, and it still reduces the runtime ABI compatibility
> question to just the kernel ABI. This tends to work really when in the
> case of dynamic languages like Python, as the language runtime is
> likely to deal with most kernel compatibility issues for you. (ABI
> incompatibilities can still bite you if you're using system libraries
> inside the container and your base image doesn't match your runtime
> kernel, but the bug surface is still much smaller than when you use
> the end user's system libraries directly)
>
> It seems to me that, at least for web services published via PyPI
> (like Kallithea), "use our recommended container", is likely to be the
> easiest way to get folks on Linux up and running quickly with the
> service. Folks may still want to take the image apart later and roll
> their own (e.g. to switch to running on a different web server or a
> different base image), but they wouldn't have to do their own
> integration work just to get started.
>
> The other advantage of nudging folks in the direction of Linux
> containers to address their ABI compatibility woes is that this is
> tech that already (mostly) works, and has a broader management
> ecosystem growing around it (including both the major open source
> platform-as-a-service offerings in OpenShift and Cloud Foundry).
> Inventing our own way of abstracting away the Linux ABI compatibility
> problem would be an awful lot of work, and likely leave us with an end
> result that isn't pre-integrated with anything else.
>
> Regards,
> Nick.
>
> P.S. Full disclosure: for Fedora's developer experience work for web
> service developers, we're heading heavily in the direction of
> containers+Vagrant for local dev workstations, to allow common dev
> workflows across Linux, Mac OS X and Windows, and then pushing the
> containers through Linux based CI and independent QE workflows, into
> container based production Linux environments, including the Google &
> Red Hat backed Kubernetes container orchestration framework and
> OpenStack's Project Solum. In my day job, this is also the direction
> we're taking Red Hat's internal infrastructure since it systematically
> solves a variety of problems for us (like how to most effectively
> allow folks to develop on Fedora while deploying on RHEL).
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150203/629301e9/attachment.html>