Thanks for explaining @alexmurray!
It’s my turn now
I believe that
$HOME/snap/<snap-name>/<snap-revision> should work for us as long as cli doesn’t notice any difference between real home and snap home. The only gripe is that it will differ from mac’s homebrew and windows’ scoop behavior that don’t seem to have such confinement and we’ll have to outline that difference for linux users.
Read access is not enough as we store enonic XP server distros there and runtime data such as XP process id and session id.
And distros are the first cornerstone of CLI.
Here is the enonic XP repo which is basically a jetty-based web-server written in Java.
CLI is capable of downloading different versions from our repository and storing them in $HOME/.enonic folder.
Starting any of these versions boils down to invoking server.sh file bundled with that distro that starts the jetty server. Using cli it is possible to stop it at any time and start a different version that comes in handy for consultants working with different versions for different clients.
Vast majority of the commands available in cli make http requests to that running enonic XP instance using API.
The other cornerstone of CLI are projects.
Projects is a way to build plugins and web-sites for enonic XP (which is a CMS). They are usually cloned from github-hosted starters like this one, edited by consultants, and deployed to locally running enonic XP instance using cli.
The main concern here is: user should be able to create projects where he wants it.
As far as I understood it from the snap policies, this is not allowed by default. If that is the case, how can it be done ?
So the bottom line is, cli does 2 things:
- downloads desired version of enonic XP server to $HOME/.enonic, starts it and makes http requests to it.
- downloads project skeletons from github, saves them to a user chosen place, builds them and deploys to XP server.