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 <[email protected]> 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 | [email protected] | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
