As a quick recap, aliases are that feature that allows people to declare more than one top-level command inside the snap instead of having available only the name of the snap itself.
After some discussions and feedback from stakeholders, we’re changing the implementation of aliases a bit so that it’s a bit more intuitive in a few places. Here is how it is going to differ from what we have in place today:
Users are now in control
In the current implementation users cannot add aliases that are not being driven by the snap author. In the new implementation the snap will lose its ability to declare aliases (no more
aliases entries necessary in
snap.yaml), and users will be able to create their own aliases without that metadata being declared anywhere else.
Consequently, the store will also need to change so that it can declare automatic aliases completely (source and target), instead of referring to something that was necessarily inside the snap.
Automatic aliases become global to the snap
Currently, the snap might declare some aliases, and the store and the user would freely select a subset of these at any one point. That’s flexible, but ended up being considered a bit too heavy for people to achieve the common case of getting the software working.
So in the new implementation automatic aliases will be, in most cases, handled as a block, being enabled and disabled together.
New user experience
As before if a set of automatic aliases is setup through the store for a snap, installing the snap will make them available:
$ snap install lxd lxd 2.12 from 'canonical' installed $ snap aliases Command Alias Notes lxd.lxc lxc - $ lxc --version 2.12
snap aliases [<snap>] can be used to list aliases in the system or for a snap and their status.
Alternatively it’s possible for the user the setup manual aliases under their control:
$ snap install hello hello 2.10 from 'canonical' installed $ hello.universe Hello, universe! $ snap alias hello.universe hi_universe Added: - hello.universe as hi_universe $ snap aliases Command Alias Notes hello.universe hi_universe manual lxd.lxc lxc - $ hi_universe Hello, universe!
the syntax is:
snap alias <snap.app> <alias>
The user can then remove them with
snap unalias <alias>:
$ snap unalias hi_universe Removed: - hello.universe as hi_universe $ snap aliases Command Alias Notes lxd.lxc lxc -
All these commands if successful report which aliases they have added or removed.
snap unalias can also be passed a snap name, in which case it disables automatic aliases for that snap and also removes all manual ones for it:
$ snap alias hello hi Added: - hello as hi $ snap aliases Command Alias Notes hello hi manual lxd.lxc lxc - $ snap unalias lxd Removed: - lxd.lxc as lxc $ snap unalias hello Removed: - hello as hi $ snap aliases Command Alias Notes lxd.lxc lxc disabled
There is also the option using
snap prefer <snap> to enable all the automatic aliases of a snap and at the same time disable all other conflicting aliases (manual or automatic) from other snaps:
$ snap alias hello lxc Added: - hello as lxc $ snap prefer lxd Added: - lxd.lxc as lxc Removed: - hello as lxc $ snap aliases Command Alias Notes lxd.lxc lxc - $ lxc --version 2.12
Requesting automatic aliases for a snap
To ask to have automatic aliases setup for a snap one can open a store category post here on the forum, listing the snap and the all the aliases, if there are ambiguities both the alias and the corresponding application need to be mentioned.
Application names that are used as target for aliases need to be stable because aliases are setup for the snap, not a particular revision, though missing applications will not break the snap installation.
To be granted, upstream precedents for command names to use as aliases, or obvious, unlikely to clash names are recommended.
Alias names differently from application names can contain