conflicts between auto-aliases and real snap names

[James Page]

Example:

sudo snap install --edge --classic openstackclients
sudo snap install --edge glance

results in:

error: cannot install "glance": snap "glance" command namespace conflicts with enabled alias "glance" for "openstackclients"

the glance snap provides the server side elements of the deployment, the openstackclients snap provides the glance CLI tool for interacting with its API; in this case the glance snap does not even have a glance command, so maybe the resolution of alias/command conflicts could be a little more fine grained - if the glance snap (the supposed primary owner of 'glance') actually declared a glance command, then this would override the auto-aliase in openstackclients; if it does not, then the openstackclients alias still wins and is used.

[James Page (james-page)]

For clarity, installing client tools server side is quite common so this should not be a a-typical thing to try todo.

[Michael Vogt (mvo)]

We will rework the alias handling. It will most likely be slightly different than this proposal here.

[Gustavo Niemeyer (niemeyer)]

The goal of preventing such conflicts is two-fold: of course we can't allow two things to coexist with the same command name because it's impossible to have both first in the path at the same time, thus one of them will overlap the other. But also, it's a matter of comprehension - having a "glance" snap which is supposed to work together with a different snap which has a "glance" alias for its own command is unnecessarily confusing. As a user, if I installed both of these snaps, it'd be extremely surprising to find out that "glance" was in fact in the "wrong" snap.

[James Page (james-page)]

I guess we could go for specialised snap package names for the daemons - say glance-api and glance-registry instead of 'glance' (which currently provides both).

This pattern is quite typical for openstack projects - the CLI for interacting with the API services is the name of the project; with the current naming approach we're taking for the server side components this currently conflicts with auto-aliasing support.