<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Wouldn't this be a good time to discuss other types of URLs?<br><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Eg:<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br>* Documentation<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">* CI status (in the many different flavors)<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">* Issue tracker<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">* Forum/mailing list<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">* Support place<br><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">After all, there's nothing special about docker images - every project is going to have a different special thing at some URL.<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div><span style="font-family:trebuchet ms,sans-serif"><span style="color:rgb(51,51,51)"><br><font><span style="color:rgb(51,51,51)">Thanks,</span><br><span style="color:rgb(153,153,153)">-- Ionel</span></font></span><font><font style="color:rgb(153,153,153)"> Cristian Mărieș, <a href="http://blog.ionelmc.ro" target="_blank">blog.ionelmc.ro</a><br></font></font></span></div></div></div></div></div>
<br><div class="gmail_quote">On Sun, Feb 1, 2015 at 2:43 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One of the recurring problems folks mention here is how to deal with<br>
the complexities of handling Linux ABI compatibility issues.<br>
<br>
That's a genuinely hard problem, and not one that *anyone* has solved<br>
well - it's one of the reasons being an independent software vendor<br>
for Linux in general (rather than just certifying with the major<br>
commercial distros) is a pain. When folks do it, they tend to take the<br>
"bundle everything you need and drop it somewhere in /opt" approach<br>
which (quite rightly) makes professional system administrators very<br>
unhappy.<br>
<br>
On the distro side, this is one of the big factors driving the<br>
popularity of the "bundle all the things" container image model: it<br>
does the bundling in such a way that it's amenable to programmatic<br>
introspection, and it still reduces the runtime ABI compatibility<br>
question to just the kernel ABI. This tends to work really when in the<br>
case of dynamic languages like Python, as the language runtime is<br>
likely to deal with most kernel compatibility issues for you. (ABI<br>
incompatibilities can still bite you if you're using system libraries<br>
inside the container and your base image doesn't match your runtime<br>
kernel, but the bug surface is still much smaller than when you use<br>
the end user's system libraries directly)<br>
<br>
It seems to me that, at least for web services published via PyPI<br>
(like Kallithea), "use our recommended container", is likely to be the<br>
easiest way to get folks on Linux up and running quickly with the<br>
service. Folks may still want to take the image apart later and roll<br>
their own (e.g. to switch to running on a different web server or a<br>
different base image), but they wouldn't have to do their own<br>
integration work just to get started.<br>
<br>
The other advantage of nudging folks in the direction of Linux<br>
containers to address their ABI compatibility woes is that this is<br>
tech that already (mostly) works, and has a broader management<br>
ecosystem growing around it (including both the major open source<br>
platform-as-a-service offerings in OpenShift and Cloud Foundry).<br>
Inventing our own way of abstracting away the Linux ABI compatibility<br>
problem would be an awful lot of work, and likely leave us with an end<br>
result that isn't pre-integrated with anything else.<br>
<br>
Regards,<br>
Nick.<br>
<br>
P.S. Full disclosure: for Fedora's developer experience work for web<br>
service developers, we're heading heavily in the direction of<br>
containers+Vagrant for local dev workstations, to allow common dev<br>
workflows across Linux, Mac OS X and Windows, and then pushing the<br>
containers through Linux based CI and independent QE workflows, into<br>
container based production Linux environments, including the Google &<br>
Red Hat backed Kubernetes container orchestration framework and<br>
OpenStack's Project Solum. In my day job, this is also the direction<br>
we're taking Red Hat's internal infrastructure since it systematically<br>
solves a variety of problems for us (like how to most effectively<br>
allow folks to develop on Fedora while deploying on RHEL).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
</font></span></blockquote></div><br></div>