@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…
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.
@niemeyer I imagine we still want to split the internal implementation though? probably means deciding which is which in api.go
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.
@niemeyer this one tries to produce the Added/Removed output we discussed initially for alias/unalias (can also support prefer):
@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.
this was the final PR cleaning up various bits/loose ends from previous work:
left todos:
aliases in snap.yaml
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?
left todos (waiting for 2.26+ to be out for a little while):
@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
Just deprecate? Should probably also raise a warning in the review tools
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?
yes, my idea was to first start with snapcraft deprecation