Improving the aliases implementation

[pedronis]

@niemeyer seems we need a way to spell “snap unalias SNAP” if we in the end think that conflating “snap unalias ALIAS” and this should not be mixed to avoid confusion.

“snap prefer SNAP” is the positive action here (but also touches other snaps), and “unprefer” anyway is strange…

[niemeyer]

Yeah, I’ve been trying to come up with a good suggestion since I’ve made that comment and I’m struggling to find something that won’t feel obscure or simply non-obvious. I don’t know if that’s because we’ve talked about it for quite a while or if indeed this is the most obvious thing to do, but I’m afraid "snap unalias " will actually be the obvious thing to do when people want that action as well. Maybe we should just give it a try and see what happens in practice. Perhaps the advantage of it being more obvious overrules the disadvantages of potential mishaps, and any mishaps can easily be fixed since we don’t destroy any actual data when disabling the automatic aliases.

[pedronis]

@niemeyer I imagine we still want to split the internal implementation though? probably means deciding which is which in api.go

[niemeyer]

Yeah, splitting the implementation seems wise since I can’t think of a reason for an application that is not just taking input from a human to want to do either blindly.

[pedronis]

@niemeyer opened also:

many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup

to adjust “snap aliases”

[pedronis]

@niemeyer this one tries to produce the Added/Removed output we discussed initially for alias/unalias (can also support prefer):

many: show alias changes on snap alias/unalias (aliases v2)

[niemeyer]

@pedronis Looking at the new documentation in the top message, I’m wondering if we should invert the output of the “snap alias” command so it looks like:

$ snap alias hello.universe hi-universe
Added:
  - hello.universe as hi-universe

This will make the snap alias/unalias commands, the snap aliases output, and the deltas reported, all present aliases in the same order, which seems like a nice win.

[pedronis]

proposed:

many: use "SNAP.APP as ALIAS" instead of => when listing added/removed aliases

[pedronis]

this was the final PR cleaning up various bits/loose ends from previous work:

many: aliases v2 cleanups

[pedronis]

left todos:

• snap install --unaliased
• snap install --prefer
• deprecate aliases in snap.yaml

[joseph.wakeling]

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?

That seems a bit of an unpleasant burden to impose on users. Is there not some reasonable way to auto-convert any existing manual aliases enabled by a user?

[pedronis]

implementing snap install --unaliased:

snapstate,many: implement snap install --unaliased

[pedronis]

@davidcalle hi, when 2.25 reaches stable we need to do something about:

Ubuntu Core – how to enable aliases for your snaps commands

[pedronis]

left todos (waiting for 2.26+ to be out for a little while):

• deprecate aliases in snap.yaml
• snap install --prefer

[pedronis]

@sergiusens @kyrofa now that 2.27 is out following 2.26 that actually introduced the change for the approach to aliases to stable is probably time to start deprecating ‘aliases’ in snapcraft.yaml itself,

let me know if I need to create a bug/issue or something else

[sergiusens]

Just deprecate? Should probably also raise a warning in the review tools

[pedronis]

that’s something for @jdstrand ( warning in review tools )?

[jdstrand]

I can do that. This will cause auto-reviews to fail so I wonder if we should wait for snapcraft to complain about it for a while. We can provide a descriptive message and optionally a URL for the review tools warning so people know how to fix from the warning alone, perhaps that is enough?

[pedronis]

yes, my idea was to first start with snapcraft deprecation

[kyrofa]

PR for the deprecation in snapcraft:

project_loader: aliases are deprecated