Currently, the deploy command in Juju is being updated to take into account the new charm repository/store called the CharmHub. One of the issues that will require ironing out is the issue around deploying a charm from a UX perspective. It might help if I explain what Juju can do when you deploy with just the charm name and ignoring all the other flags for customisation.
Note: I’m omitting bundles for the moment, as they act in almost the same way.
Standard
Charmstore
The basic standard one, just deploy with the CharmStore prefix (cs), nothing special does exactly what you thing and grabs the latest redis
juju deploy cs:redis
Charmstore versions
Additionally to the standard CharmStore, you can also pass optional extras to target specific versions of the charm. For example, you can pass in a user (jameinel), the series you want (bionic) and the charm name (ubuntu-lite) and finally the target revision (7).
juju deploy cs:~jameinel/bionic/ubuntu-lite-7
Local
Accompanying the CharmStore declarations you can also identify a charm via your local filesystem. Super handy if you’re developing locally or are air-gapped.
juju deploy ./charm
Aliases/Alternatives
All of these are obvious well-trodden axioms from the Juju documentation/tutorial perspective. Yet there are some declarations for deploy that can be used that are less utilised, but are valid.
Charmstore without a prefix
This one is used, especially by me when testing, but is always inferred by the charm URL parsing library to always means CharmStore. If the cs: is missing, it will always prefix the charm name with it.
For example juju deploy redis becomes juju deploy cs:redis, excellent!
Depending on your shell (not in zsh, you need to quote the charm URL) you should also be able to do juju deploy ~jameinel/xenial/ubuntu-lite-7.
Charmstore using a URL
This one was surprising to me, but you can also juju deploy with a fully-qualified URL. The domain in question doesn’t matter at all, it just re-writes the URL to something that resembles the V1 (let’s call the fully-qualified URL V2) charm URL.
juju deploy http://juju.is/redis
Interestingly https also works, but it must be said, no network connection is used at this point, we’re just re-writing the URL to the V1 URL. So it becomes cs:redis.
You can do the versioning in the URL, to match the origin CharmStore URL.
juju deploy https://ubuntu.com/u/jameinel/ubuntu-lite/xenial/7
Which becomes juju deploy cs:~jameinel/xenial/ubuntu-lite-7
Issues
Local prefix
Interestingly the charm URL library supports the addition of using a prefix (local:), but unfortunately, the charm URL doesn’t support the parsing of the URL if it has the local: prefix.
juju deploy local:~/some/charm # doesn't work!
Charmhub
So what does this have to do with the CharmHub?
To transition over to the CharmHub and to allow for the CharmStore and the local charm URLs to co-exist, we want the user to have the intention of stating that they intend to target a particular store.
Either that’s with a feature flag, that we turn on and state that all non-local charm URLs will be pushed towards the CharmHub, or we state that anything without a cs: prefix is intended for the CharmHub. The downside to the latter is that we prevent some of the above from working and that might be a breaking change for some users of the CLI (and I fall into that category!).