I’m not sure I get your question, so please correct me if I’m on the wrong track.
The sudo is needed because in general it seems nice to assume people are not running all commands as root, but instead as their usual user, so the sudo increases the privilege of the command following it to that of the system administrator. That said, when running commands inside a lxd container or similar, the root is more also more isolated and thus more natural, so you might not need it.
The ‘$ snap version’ command line output is system dependent i.e. on Ubuntu 18.04 LTS the output is:
snap 2.36.1
snapd 2.36.1
series 16
ubuntu 18.04
kernel 4.15.0-39-generic
This topic should also include the installation and initialization of multipass, since snapcraft defaults to it.
Simply installing the multipass snap is not enough apparently, I had to execute multipass launch to make sure multipass is initialized before running snapcraft. I’m not sure if there is an easier way to initialize multipass.
I think you may mean we need to update Snapcraft overview to show how multipass is initialised? I’ll check with a fresh install and see whether some extra steps are needed. The last time I did this, multipass was installed automatically.
Just pointing out that the image immediately following this text seems to show that the data associated with the snap is retained if it has been modified – which is it?
Thanks for flagging this, and you’re right that the image is misleading. I’ll either update it or replace it, and add further details to the text to make this clearer. The answer actually depends on where the snap stores its data.
If the data is in a common directory (SNAP_USER_COMMON or SNAP_COMMON for the snap developer) then there’s only one instance of the data available across all revisions of the snap, regardless of any revision-specific modifications.
If it’s within a revision-specific folder (SNAP_DATA and SNAP_USER_DATA for the snap developer), then the diagram is correct - data associated with a revision normally migrates forwards, but not backwards after a revert.
Additionally, there’s also data saved in a Snapshot.
This is covered in Data locations, but I agree, it should be simplified and rewritten here.
Is it worth mentioning the “–verbose” option to “snap info”, as in “snap info --verbose vlc”?
Further down:
"List all available revisions
The following command lists all revisions available for every installed snap, and also highlights which particular revisions are disabled at the moment:
$ snap list --all vlc"
No, that command does not list all revisions “available for every installed snap”, only for vlc.
“Adding /snap/bin to your default $PATH makes running snaps that don’t automatically add themselves more convenient.”
Interestingly, not only should the user not have to do that (on my Ubuntu 22.04 system, that entry is already appended to my PATH) but, oddly, it’s appended twice. As in, it appears that installing snapd somehow adds that directory to one’s PATH twice. Doesn’t hurt, of course, just unnecessary.
Is it worth mentioning the “–no-wait” option for “snap remove”?
Regarding the discussion of whether or not to keep including “sudo” in sample commands, perhaps early on in this page, add an emphatic note that one can register for a SSO account, then use “snap login” to obviate the need for constant “sudo”.
When you early on refer to “even running two versions of the same application at the same time” are you talking about parallel installs? Because I don’t see that explained on this page.
I found this misleading on first read; I thought that the snapshot gets stored in $HOME/snap/<snap-name> and /var/snap/<snap-name> instead of the data that gets snapshoted.
Maybe a sentence like this will make this clearer:
A snapshot of the data that can be found in $HOME/snap/<snap-name> and /var/snap/<snap-name> will be stored in /var/lib/snapd/snapshots/ (see Data locations for more details).