dpkg compatibility

[Barry Warsaw]

On Nov 12, 2015, at 12:54 AM, Mark Shuttleworth wrote:

>We observed over the years that there was lots of content and code that
>did not fit easily into the deb packaging system, that's why upstreams
>often recommend that you use systems like pip rather than deb packages
>of Python libraries. Snapcraft essentially lets you use pip, npm, and
>the equivalents from Java and other languages, very easily. We've also
>noticed that there is loads of software on Launchpad and Github which is
>moving too fast to meaningfully package it as debs and give it a stable
>9 year support cycle. That stuff all goes very nicely into snaps.

The other nice thing about the snapcraft approach is that it won't be subject
to the same constraints that often impose less than ideal restrictions on the
debs.

For example, some upstream Python packages bundle ("vendor") their
dependencies to better ensure compatibility, but that vendorizing often has to
be unwound to comply with Debian policy.  We of course try to make that work
as best we can in the context of an integrated OS platform, but it can get
rough around the edges, it's always a balancing act, and it always delays
getting the latest upstreams into the archive.

Another problem we see is that of multi-version constraints.  Sometimes your
code depends on version W of a library but version X is in the archive, for
whatever reason.  PyPI usually keeps multiple versions around, which can be
pulled in by more specific version-tagged requirements.

By snapcrafting essentially what a pip user would see, you avoid those issues,
and I think it gives folks a lot of the flexibility they really want.  There's
a reason why Python developers love virtual environments!

Cheers,
-Barry