Hello
The Juju client is currently named Juju. This fact stops a beginner from getting started quickly in learning Juju. A newbie typed in “sudo snap install juju” and thought he installed Juju in simple mode, without HA. In fact, Juju consists of three components: Juju client, Juju Controller, and Juju agent, but Juju client is not called a Juju client.
In my opinion, to rename “Juju” to “Juju client” would be a good help for beginners
Absolutely
This is a good point! It would help address one of the more frequently asked questions/points of confusion.
juju-client isn’t the most exciting name, though. charmctl might be nicer (jujuctl is awkward).
Just to be clear: I’m not in the right place in Canonical’s org to have much influence over the name. I simply like the suggestion a lot 
FWIW, this has been a topic of discussion. We’re currently doing the work to strictly confine the Juju snap, and one option after that’s done could be to publish a “juju client” snap of some sort. Note that the Juju snap today contains 2 executables - the client and the jujud agent. The agent is there because it allows the snap to be used to launch a controller (albeit of the same arch as the client) where there’s no external access to download the published agent tarball.
The other thing to consider is just what is meant by “client”. If you want / need to launch a new controller and later tear it down, the client needs to have lots of extra code baked in to be able to operate any of the supported cloud APIs. However, if you just want to operate an existing controller, create models, manage workloads etc, then the client can be much smaller as it just needs the core Juju APIs. What this translates to in real world binary sizes given everything is compressed etc needs investigating. If the size on disk of the “full” client is reasonable, having a truly thin client would not pay its way given the extra complexity in documenting the limitations etc.
So you can see there’s a little to think about. Possible options:
Given how confusing it would be to new folks to grasp the subtle differences, maybe the easiest option is simply to publish a second “juju client” snap with the same content as what we have now in the juju snap?
As an aside, a while ago there was talk of a considering a “microjaas” snap to provide a simple snap install of a working Juju controller, similar to what microk8s does for Kubernetes. This would align more with what the original poster was alluding to perhaps.
You can separate:
And make a dependencies. Then it would be possible to independednt release cycle for client and agent 
PS extra code baked - it’s not bad, client is a broader concept than command line interface (cli)
We are having major issues with snaps everywhere. The recent auto-updates impacted us to a point that I am 100% blocked in all tasks until I can figure out a way to have a local Juju dev environment working again. See https://github.com/canonical/charmcraft/issues/685 as the latest snap-fiasco.
Please provide either .deb installers for Juju and/or documentation on how to install the client and bootstrap a controller without using snaps at all.
CC @jamesbeedy
I can’t speak for charmcraft (that’s a separate team), but with Juju, we are very careful not to break compatibility when a new version is published. In theory, any Juju 2.x client (all the way back to 2.0) can talk to any Juju 2.x controller. The client and controller negotiate what API versions each one supports and they Do The Right Thing. We have had maybe one or two at most issues over the many years Juju 2.x has been a thing, and these were considered urgent bugs which were quickly fixed.
Given the above, non using a snap for the Juju client won’t gain you anything. If you do really, really want to avoid it, we do publish for each release binaries for each arch as a tarball on the relevant milestone page, eg 2.9.25.
Very interesting note about versions client and controller 
Beginner may not be immediately clear that the versions of the controller and the client may differ. And you do not immediately understand that the client will not tell you that the version of the controller has become older than the client
Helping users understanding the architecture of juju is important and separate client from server /controller makes sense.
How about juju-cli vs jujuctl?
About the snap…
It does cause many issues. Especially on non Ubuntu os:es. Juju will never be a tool outside of Ubuntu with this approach. Perhaps Canonical do not care about this detail, but the community will not grow outside of it either.
A technical issue I’ve had in the past, in multiuser environments with NFS backend for /home - snap is not happy and neither are users.
“separate client from server /controller” You got caught too! Juju snap not contain controller )
About snap - snap is awesome idea Canonical for delivery way programs, but community may be create fltapak as alternate 
Deb/rpm package is not the only way
would be a good help for beginners
That’s a good point.
