Improving the aliases implementation

Hello all,

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 _ or ..

3 Likes

Will this break backward compatibility? What do we intend to happen when a snap which is declaring aliases is installed on a snapd where this ability has been removed?

It will not break backwards compatibility for automatic aliases because the new snap-declaration language will be in place by the time we release a snapd with the new mechanism. This will be put in a different field, so we don’t break previous snapds that still rely on the old language.

That said, it will break backwards compatibility mainly in cases where we have manual aliases in place, because the cost of handling all the possible permutations of these cases doesn’t seem worth the cost of development of that specific migration path. There’s still time to change that decision if there’s strong disagreement or data proving otherwise, but I’d prefer to keep that path otherwise.

To make sure I understand: currently, individual snaps can declare aliases for their apps, but such aliases are not automatically enabled upon installation unless the snap-declaration assertion says so. Correct? Assuming I understand that, then what you say makes sense.

“manual aliases” being when the user runs snap alias themselves?

So say I maintain a snap that declares aliases, but has nothing in its assertion to automatically enable them. Let’s also say that the snapd which stops recognizing the declared aliases was just installed in an update.

  1. If a user has my snap installed but done nothing with snap alias, the only affect of this update is that the user will need to enable aliases in another way (or perhaps the snap alias command changes somewhat). Correct?
  2. If the user has my snap installed and has enabled the aliases manually via snap alias, these aliases will be removed by this update. Correct?

Right. For the typical case of people just using automatic aliases, the migration won’t be perceived and the only breakage will be in the behavior of the alias command.

As of right now, yes, this is correct.

Alright. Please let us know when we should deprecate aliases in snapcraft.

Work on this is proceeding, this related PRs were already merged:

https://github.com/snapcore/snapd/pull/3021
https://github.com/snapcore/snapd/pull/3030
https://github.com/snapcore/snapd/pull/3029

1 Like

The next PR has been updated to follow the last decisions with aliases state for a snap stored in its SnapState:

https://github.com/snapcore/snapd/pull/3044

@niemeyer

1 Like

@pedronis PR #3044 reviewed.

1 Like

This PR needs a 2nd review. It this marked blocked pending having the timeline for 2.24 vs 2.25 clarified: once it’s merged we cannot make a stable release until the new “snap alias”/“snap unalias” are implemented:

https://github.com/snapcore/snapd/pull/3082

@pedronis As mentioned there, can’t say it looks good since this is just the disabling step, but hopefully a solid step towards having the new semantics in place.

PR with tasks and handlers (with temporary “-v2” names for now) to implement most of the new semantics for install/refresh:

https://github.com/snapcore/snapd/pull/3087

another PR is coming soon switching over install/refresh etc and with migration code.

@niemeyer I now also proposed a PR that does the main switch to the new tasks and semantics and introduces the Ensure transition to v2 aliases:

https://github.com/snapcore/snapd/pull/3137

@niemeyer based on discussion and review feedback I created:

https://github.com/snapcore/snapd/pull/3155

and then merged it to simplify things in:

https://github.com/snapcore/snapd/pull/3087

they are both ready for review

1 Like

I merged #3155

as I mentioned #3087 can be re-reviewed,

and this one should be reviewable as well (it builds on top of #3087 but it’s relatively orthogonal changes and deletions on top of that)

https://github.com/snapcore/snapd/pull/3137

@pedronis LGTM, thanks. Sent a couple of comments there, but okay to consider later.

@niemeyer I tried to answer the comments, but indeed they can/will be covered by follow ups

also there was an issue with the recent changes and #3137 which should be fixed now

I merged

https://github.com/snapcore/snapd/pull/3082

which means alias commands will be broken until we land the new implementations for 2.25

@niemeyer all the following PRs are now ready for review or at least a first pass review (they build on each other though):

https://github.com/snapcore/snapd/pull/3137
https://github.com/snapcore/snapd/pull/3191
https://github.com/snapcore/snapd/pull/3192

they have TODOs as needed in their descriptions, I also progressed quite a bit on a branch to implement "snap prefer " but that one is not quite ready for review.

Now there’s also a PR ready for review giving a try at “snap prefer”:

https://github.com/snapcore/snapd/pull/3220