deploy: check for nameclash first

[Jordan Barrett]

When you try to deploy a charm with a name that's already taken:
```
$ juju deploy juju-qa-test
Located charm "juju-qa-test" in charm-hub, revision 13
Deploying "juju-qa-test" from charm-hub charm "juju-qa-test", revision 13 in channel stable on bionic
ERROR cannot add application "juju-qa-test": application already exists:
deploy application using an alias name:
    juju deploy <application> <alias>
or use remove-application to remove the existing one and try again.
```
Surely we should check if the name is taken **before** doing the (expensive) work of locating/downloading/deploying the charm?
```
$ juju deploy juju-qa-test
ERROR cannot add application "juju-qa-test": application already exists:
deploy application using an alias name:
    juju deploy <application> <alias>
or use remove-application to remove the existing one and try again.
```

[John A Meinel (jameinel)]

So the issue is that `juju deploy PATH` is defining the path to an object that we will be deploying, but until we grab the charm metadata.yaml, we don't actually know the name of the application. (for example `juju deploy jameinel-ubuntu-lite` today actually deploys an application named 'ubuntu-lite' because that is the 'name: ubuntu-lite' that exists in metadata.yaml

So at a minimum, juju needs to do the resolution to find the name of the application.

In 3.0, we should only be doing a query against charmhub to find the metadata.yaml, and not doing a full charm download.

In one respect it "would be nice" if you couldn't mismatch the official deployed name of the app from the charmhub name.
At least one problem with that is that Charmhub is (by design) a flat namespace. So if there is an "official" mysql charm, and you want to fork it and customize it, you have to then rename it to something like `jbarrett-mysql`. Do you want jbarrett-mysql to show up as `mysql` in the model by default, or as `jbarrett-mysql` always?
(I can certainly see an argument for the latter, but there are already fields around 'charm url' that can tell you what exactly you have deployed.)

Going further, there are also issues like 'charmcraft pack' creates a file named:
juju-qa-test_ubuntu-18.04-amd64_ubuntu-20.04-amd64_ubuntu-22.04-amd64.charm

We would certainly then need some sort of obvious name mangling to strip of pieces of that to get the 'official' name.

[John A Meinel (jameinel)]

(In 3.0, we at least don't download the entire charm contents, just to resolve the official name, hopefully that helps with some of the desire here.)

[John A Meinel (jameinel)]

Note that we could look for a conflict in the syntax `juju deploy foo bar` where the latter is an explicit user override to the name provided by the charm. I'm not sure that it actually improves the user experience enough to be worthwhile. (If you feel it would, then we can re-open this.)

[Jordan Barrett (barrettj12)]

Ah right, I assumed that if you run
    juju deploy foo
then the application name would just be "foo". If that's not the case then I can see why the logic doesn't hold up.

Some more ideas just to prevent the user having to re-download the charm:
 - cache downloaded charms locally, they can then re-run the command immediately after without incurring another download cost.
 - when a nameclash arises, prompt the user for an alias instead of just exiting.

[John A Meinel (jameinel)]

So in 3.0 the charm doesn't get downloaded to the client at all, so I don't
think that portion is a problem. I would also think that the controller
will be caching the content of the charm.
As a general rule, we avoid prompting in the juju client, because it is
used interactively about as much as it is driven by scripts (and scripts
really can't handle interaction).
We *do* interaction for some commands like bootstrap and destroy (though
generally with a flag to avoid that interactive prompt).

On Wed, Aug 24, 2022 at 8:00 PM Jordan Barrett <email address hidden>
wrote:

> Ah right, I assumed that if you run
> juju deploy foo
> then the application name would just be "foo". If that's not the case then
> I can see why the logic doesn't hold up.
>
> Some more ideas just to prevent the user having to re-download the charm:
> - cache downloaded charms locally, they can then re-run the command
> immediately after without incurring another download cost.
> - when a nameclash arises, prompt the user for an alias instead of just
> exiting.
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1977908
>
> Title:
> deploy: check for nameclash first
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1977908/+subscriptions
>
>