<div dir="ltr">Thanks, Leo. Do you already have snaps for similar programs (e.g. screen, tmux, ssh)? Mosh is probably going to have similar needs to those re: the isolation or "plugs".<div><br></div><div>Generally we add new platforms/distros when somebody submits a PR or volunteers to be a maintainer; my suggestion is for you to just submit a PR with a proposed snapcraft.yaml (and changes to .travis.yml if appropriate) and we can all try it out.</div><div><br></div><div>Cheers,</div><div>Keith</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 13, 2017 at 7:56 AM, Leo Arias <span dir="ltr"><<a href="mailto:yo@elopio.net" target="_blank">yo@elopio.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Jan 12, 2017 at 11:59:53PM -0800, Keith Winstein wrote:<br>
> Right now we have a Debian package, which we maintain in our own source<br>
> tree, and which we upload to Debian every time there's a new release. That<br>
> flows into Ubuntu as part of the normal release schedule. For users who<br>
> want something more immediate, we also have the mosh-dev PPA that pulls<br>
> from our GitHub repository once a day and auto-builds the Ubuntu source and<br>
> binary packages, and then we have a "stable" mosh PPA as well, which only<br>
> gets updated on new releases.<br>
<br>
</span>That is great because we would love to hear your impressions, taking into<br>
account your experience with debs and PPAs.<br>
<br>
In classic Ubuntu you have to follow our 2 years/6 months release cycle, or use<br>
a PPA. When you release a deb to an LTS, you will quickly get many users in an<br>
outdated version for many years, you need maintainers to review your package to<br>
make sure it's compatible with the archive, and you need to follow a<br>
heavy-weight format full of conventions and rules to make the archive<br>
consistent. debs are great for some projects and some users, and we are using<br>
them as a base for our new Ubuntu Core distro; but something like getting the<br>
mosh 1.3.0 to xenial, or even to trusty, it's a huge pain.<br>
<br>
That's what we are trying to improve with this new dev experience. Snaps are<br>
mounted read-only directly from the uncompressed package and they bundle all<br>
their dependencies. So there is no conflict between snaps, nor with the base<br>
system, and then we can get out of your way, you don't need the distro as a<br>
middle man and you can just push to the store any version you want, any time<br>
you want.<br>
<br>
Snaps are also isolated to their sandbox for security reasons. But there's<br>
where things get interesting with mosh...<br>
<span class=""><br>
> Is it possible to teach Launchpad to also auto-build a snap once a day (if<br>
> our Git repo has changed), alongside the PPA .debs? Can we script Travis-CI<br>
> to automatically build and push a snap each time it runs a successful CI<br>
> test on the master branch? Or how would you recommend we do this?<br>
<br>
</span>Yes, we want the snapcraft.yaml metadata to be as simple as possible, and to<br>
use continuous deployment, so you will just have to spend a little time<br>
packaging one time, and then everything is automatic. You can take a look here:<br>
<a href="http://snapcraft.io/docs/build-snaps/ci-integration" rel="noreferrer" target="_blank">http://snapcraft.io/docs/<wbr>build-snaps/ci-integration</a><br>
<span class=""><br>
> Mosh is pretty simple so I doubt we're going to be pushing the boundaries<br>
> of the snap format -- it's basically two unprivileged binaries and some man<br>
> pages. And a bash-completion script that gets put<br>
> in /usr/share/bash-completion/<wbr>completions/mosh. I guess that might be a<br>
> little more interesting, depending on whether snap can handle that.<br>
<br>
</span>If I understand correctly, the mosh server is a terminal emulator. (I'm not<br>
sure about mosh internals, so I'm eager to understand more about that too :)<br>
By default, snaps can't do anything outside of their confinement, so things<br>
like calling binaries they don't provide or accessing devices will be blocked.<br>
And that's good enough for the vast majority of applications out there, they<br>
just declare a few "plugs", like listening to the network, and they can fully<br>
function. But now we are turning our eyes to also support developer tools, like<br>
emacs which needs to be able to read and write to /etc, or a shell like zsh, or<br>
mosh.<br>
They pose a bigger security risk than normal apps, but still we think it should<br>
be a direct agreement between the user and the developers distributing that<br>
package. So you would declare on your snap the kind of things that your<br>
application will do out of its confinement, and the user decides to grant that<br>
permission or not.<br>
<span class=""><br>
> Happy to work with you on this if you think there is user demand for it.<br>
<br>
</span>Well, I'm sure it will make it easier for you to do early testing of the new<br>
release, and once you are ready to release to the stable channel, many of your<br>
users on current Ubuntu versions will find the update in the store and make the<br>
jump.<br>
<br>
But as I said above, we are trying to make it extremely lightweight, so it<br>
shouldn't take a lot of your time. Developers usually just start by dumping an<br>
existing binary into the snap, and use the devmode confinement to get a list of<br>
the security exceptions that they need. Then if you like, you can build the<br>
binary during the snapcraft packaging, which will make it easier to provide the<br>
snap for other architectures.<br>
<br>
I'm about to leave for vacations, so I encourage you to take a look at<br>
<a href="http://snapcraft.io/create/" rel="noreferrer" target="_blank">http://snapcraft.io/create/</a> and give it a quick try. Then when I return the<br>
following week I would be happy to answer any of your questions, and give you a<br>
hand with the packaging if you need it.<br>
<br>
I'm sorry for the long email, but I'm excited about snaps and mosh, and really<br>
eager to hear your comments :)<br>
<br>
pura vida<br>
</blockquote></div><br></div>