The image devel alias is confusing

[seb128]

Using 1.5.0(2857) on Ubuntu 20.10

$ multipass find | grep hirsute daily:21.04 devel,hirsute 20201111 Ubuntu 21.04

$ multipass launch devel launch failed: Unable to find an image matching "devel"

$ multipass launch hirsute launch failed: Unable to find an image matching "hirsute"

The aliases as listed today are confusing since they are not working, could the find list be updated to mention 'daily:hirsute' if that's what is needed? If not maybe the error could help with some boilerplate 'image not found, you might need to prefix with a daily source'...

[townsend2010]

Yes, we've struggled with how best to present this situation. The problem is, if we prepend daily: (or some other remote), the string is going to very long or the output will look even more cluttered.

To be fair, multipass launch -h does say this: If <remote> is omitted, ‘release’ will be used. I know it's not ideal, but at least we do document that :wink:

That said, we can make the help in find better by explaining how to map the find output for launch.

[seb128]

You could probably special case at least 'devel' and mention in the error that that's one that is coming from the daily remote?

[townsend2010]

Really, the problem here is the omission of the remote when launching. We make an assumption, as stated in the launch help, that if <remote:> is omitted, then the release remote is used. We could require the remote in all cases and then this would not be an issue.

I'm not sure if making devel a special case is the right answer either. We also have other supported remotes which could have a devel alias as well or when we allow users to add their own custom remote, they may use a devel alias.

One thing that comes to mind for the find output, we could replace the Image column with a Remote column to make it more explicit and then list all aliases in one column. Something like:

Remote             Aliases               Version          Description
                   core,core16           20200818         Ubuntu Core 16
                   core18                20200812         Ubuntu Core 18
                   18.04,bionic          20201112         Ubuntu 18.04 LTS
                   20.04,focal,lts       20201111         Ubuntu 20.04 LTS
                   20.10,groovy          20201111         Ubuntu 20.10
daily:             21.04,devel,hirsute   20201111         Ubuntu 21.04

And then in the help, explain the Remote and Aliases columns and how to use them in launch. If Remote is blank for a given row, then it's not necessary to give it in launch. If the remote is listed in the row, then it's required in launch.

[seb128]

Having a column for the remote makes it easier to understand instead

[townsend2010]

Thanks @seb128, good to have feedback from a user!

@Saviq, @ricab, @luis4a0, any thoughts on my proposal for the find output in https://github.com/canonical/multipass/issues/1842#issuecomment-729046226?

[luis4a0]

Hey @townsend2010, thanks for taking care of this. I think the output is indeed more clear from a user POV. Perhaps we could specify the default remote in the blank entries of the first column: that will save us complex explanations in help launch and make it clearer for the user.

[townsend2010]

After some internal discussion, here is the latest proposal:

Remote             Aliases               Version          Description
snapcraft          core18                20201111         Snapcraft builder for Core 18
snapcraft          core20                20201111         Snapcraft builder for Core 20
snapcraft          core                  20201112         Snapcraft builder for Core 16
N/A                core,core16           20200818         Ubuntu Core 16
N/A                core18                20200812         Ubuntu Core 18
release            18.04,bionic          20201112         Ubuntu 18.04 LTS
release            20.04,focal,lts       20201111         Ubuntu 20.04 LTS
release            20.10,groovy          20201111         Ubuntu 20.10
daily              21.04,devel,hirsute   20201111         Ubuntu 21.04
appliance          adguard-home          20200812         Ubuntu AdGuard Home Appliance
appliance          mosquitto             20200812         Ubuntu Mosquitto Appliance
appliance          nextcloud             20200812         Ubuntu Nextcloud Appliance
appliance          openhab               20200812         Ubuntu openHAB Home Appliance
appliance          plexmediaserver       20200812         Ubuntu Plex Media Server Appliance

[seb128]

The output described there is clear and quite an improvement, thanks!

[Saviq]

Personally I dislike the separate Remote column. I don't really see how it makes it clearer that you have to launch daily:devel, as opposed to just launch devel. I also dislike the "N/A" where the remote is empty.

IMO the current find output is a compromise between verbosity and readability.

There's actually a discrepancy in behaviour with our help text, which could help this compromise stand:

$ multipass help find
# ...
                      If <remote> is omitted, it will search ‘release‘ first,
                      and if no matches are found, it will then search ‘daily‘.
# ...

Implementing the above would make launch devel work, without the need to make the find output refer to "Remotes".

[seb128]

@Saviq that's nicer indeed, guiding the users to the solution is better than improving a documentation that they might not read (or go check out of frustration because the 'obvious' approach isn't working).

One other solution if you don't want to magically fallback to daily would be to hint of the available alternative (similar for example to the command not found suggestions)

$ multipass launch hirsute
Unable to find an image matching "hirsute" in the "release" remote but there you could try with other remotes
    multipass launch daily:hirsute    # version 2020110
    multipass launch other:hirsute    # version experimental
    multipass launch tested:hirsute   # version daily verified

[Saviq]

Yes, I was also considering a "Did you mean devel:hirsute?", that will still be an option regardless of implementing the daily: fallback.