User Story
As a user of Sleeper, I want to easily understand what tools are available to interact with it.
Description / Background
Split from:
At time of writing we have a tool that we call the Sleeper CLI (Command Line Interface), but it's not really a CLI for Sleeper.
It provides a setup to avoid the need to manually install dependencies, and to simplify the process of configuring an AWS account to deploy Sleeper into. We'd like to give it a better name that more intuitively captures this, and distinguish it from the scripts that act as the CLI for Sleeper in practice.
Technical Notes / Implementation Details
The code for this tool is in scripts/cli. We'll want to rename that directory.
When you install it with scripts/cli/install.sh, it copies the script scripts/cli/runInDocker.sh into your user home directory under ~/.local/bin, and adds that to your system path. It renames that script so that you can then run it as sleeper on the command line. This is a bit confusing on its own.
This is documented in the following article, and referenced in many places in the documentation:
https://github.com/gchq/sleeper/blob/develop/docs/deployment/cli-deployment-environment.md
We could consider how we might split out issues for the documentation changes, but it wouldn't make much sense to change its name without also updating the documentation.
The GitHub Actions workflows will need renaming, as well as the status badge in the project readme.
Naming the tools
Thinking of it as "the run in docker script" might make more sense, but it's a bit vague.
Thinking of it as "the builder container" and "the AWS account setup container" might make sense, though it might make it a bit fragmented.
We have plans in the future to create a unified Sleeper CLI that would include both this tool and what's currently covered by the scripts. With what's in it now, it doesn't make much sense to call it a CLI, since you need to use the scripts to do things you'd expect a CLI to do.
One option would be to create a stub inside the CLI for interacting with an instance, and just have it send you in the scripts folder for now. In that case, we could move the Docker-based tools into a sub-section of the "CLI". That approach has the disadvantage that it's still confusing that it's not really what you need to interact with Sleeper, but it would at least make the intent clearer.
User Story
As a user of Sleeper, I want to easily understand what tools are available to interact with it.
Description / Background
Split from:
At time of writing we have a tool that we call the Sleeper CLI (Command Line Interface), but it's not really a CLI for Sleeper.
It provides a setup to avoid the need to manually install dependencies, and to simplify the process of configuring an AWS account to deploy Sleeper into. We'd like to give it a better name that more intuitively captures this, and distinguish it from the scripts that act as the CLI for Sleeper in practice.
Technical Notes / Implementation Details
The code for this tool is in
scripts/cli. We'll want to rename that directory.When you install it with
scripts/cli/install.sh, it copies the scriptscripts/cli/runInDocker.shinto your user home directory under~/.local/bin, and adds that to your system path. It renames that script so that you can then run it assleeperon the command line. This is a bit confusing on its own.This is documented in the following article, and referenced in many places in the documentation:
https://github.com/gchq/sleeper/blob/develop/docs/deployment/cli-deployment-environment.md
We could consider how we might split out issues for the documentation changes, but it wouldn't make much sense to change its name without also updating the documentation.
The GitHub Actions workflows will need renaming, as well as the status badge in the project readme.
Naming the tools
Thinking of it as "the run in docker script" might make more sense, but it's a bit vague.
Thinking of it as "the builder container" and "the AWS account setup container" might make sense, though it might make it a bit fragmented.
We have plans in the future to create a unified Sleeper CLI that would include both this tool and what's currently covered by the scripts. With what's in it now, it doesn't make much sense to call it a CLI, since you need to use the scripts to do things you'd expect a CLI to do.
One option would be to create a stub inside the CLI for interacting with an instance, and just have it send you in the scripts folder for now. In that case, we could move the Docker-based tools into a sub-section of the "CLI". That approach has the disadvantage that it's still confusing that it's not really what you need to interact with Sleeper, but it would at least make the intent clearer.