<div dir="ltr">Hi Gordon,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 24, 2016 at 12:13 PM, Gordon Ball <span dir="ltr"><<a href="mailto:gordon@chronitis.net" target="_blank">gordon@chronitis.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 * The package contains multiple binaries, and the links in /snap/bin<br>
are named, eg `cufflinks.cuffdiff`, which makes them incompatible with<br>
existing scripts.</blockquote><div><br></div><div>As you can imagine the problem here is namespacing. Unlike in traditional Linux distributions, the application names inside snaps are not curated to prevent conflicts, so the naming scheme we have put in place allows everybody to own the namespace under their own snaps with that scheme.</div><div><br></div><div>That said, we understand this is not optimal because, as you say, it breaks existing scripts. We have two alternative plans for how to sort this out, and will put one of them in place very soon.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Additionally, I can't declare `apps:` keys with<br>
underscores in them, so some come out completely misnamed.<br></blockquote><div><br></div><div>This is related but slightly orthogonal. We indeed restrict the charset used to name commands, both to enable predictable delimiters in some contexts, and also to make the system feel saner to the user. The vast majority of application names fit in the current constraints, so the question is whether it's best to have a consistent naming scheme for the user, or whether it's best to attempt to support more cases for the developer (underscores, uppercases, dots, ...). We don't have an answer yet.</div><div><br></div></div><div class="m_8794362250023349394gmail_signature"><br>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div></div>