Top-level package names, UX questions

[Michael Vogt]

On Mon, Feb 23, 2015 at 04:43:14PM -0200, Martin Albisetti wrote:
> Hi all!
Hi Martin,

> We've kicked off the work to support top-level package names (eg
> "apache" instead of "apache.beuno"), and plan to work on it in a few
> iterations, each adding a bit of usefulness each time.

Great, thanks a lot!

[..]
> With all that context in mind, I'd like to get some feedback on where
> and how to specify the package namespace.
> As I see it, we have 3 options:
> 1) It's not specified at all in the manifest file in the package, the
> metadata for that is provided separately by the store all together
> 2) The package's manifest always contains the developer's package
> namespace (apache.beuno), and the store provides the metadata
> separately
> 3) The package's manifest contains the top-level namespace

4) We also have the option that the package name in the
meta/package.yaml is the name in the store. So either "apache.beuno"
or "apache". That of course means that in order for a package to
become a top-level namespace package it needs to be re-uploaded once
with the new name "apache" and there is no automatic transition
(we could provide automatic transition via a simple alias in the
store, but to me it feels odd when a package apache.beuno suddenly
changes the on-disk name and possible the command name).
 
> The pieces affected by this decision are:
> a) Path on disk (/apps/packagename)
> b) How to execute binaries in the package (apache.start)
> c) What the developer specifies (or has to remember to specify!) in the manifest
[..]
> Options 2 and 3 are similar enough, that I think it mostly comes down
> to how it affects the pieces identified before. I wouldn't want you to
> have been running "apache.beuno.start" for a year, and then suddenly
> with an update it stops working because it gets upgraded to
> "apache.start".

What I dislike about 2+3 is that the location on the filesystem and
the commands depends on data from outside the snap. I.e. if you
re-pack /apps/apache and install it on a different system it may end
up as /apps/apache.beuno there because some store meta-data is
missing (not a big deal, but it feels cleaner if the snap is
self-contained to me).

What I like about option (4) is that its simple and predictable. You
install apache.beuno and its /apps/apache.beuno/$version. You install
"apache" and its /apps/apache/$version. The binary names stay the same
etc.  It also makes side-loading easier, all meta-data is in the
package name.

We could provide some info feature for the transition, i.e. if
apache.beuno becomes apache we could show a message on update that the
package got a new name.

Cheers,
 Michael