weaviate / weaviate-cli

CLI tool for Weaviate
https://weaviate.io/developers/weaviate/client-libraries/cli
BSD 3-Clause "New" or "Revised" License
11 stars 11 forks source link

SUGGESTION: Create sandboxes with --sandbox --create #13

Closed bobvanluijt closed 5 years ago

bobvanluijt commented 5 years ago

It would be good to be able to create sandboxes via the weaviate-cli.

Use case: Create a sandbox in one go via the CLI tool.

$ weaviate-cli --sandbox --create

(I'm suggesting --create because we might want to be able to add --extend or --remove functions later.)

Additionally I would like to suggest:

$ weaviate-cli --sandbox --create --current

The --current flag means that you don't have to rerun weaviate-cli --init and that it automatically sets it as the current Weaviate.

PS: The Sandbox API includes more variables that currently are not part of the suggested commands above or the --init function. I would like to use this issue to discuss the final design. cc: @etiennedi

etiennedi commented 5 years ago

I would like to use this issue to discuss the final design. cc: @etiennedi

If we're discussing design I'd also like to mention something that is technically off-topic to this suggestion, but would also affect the final design here.

Currently, the cli tool uses flags for everything, however, some flags should in my opinion actually be commands. For example, weaviate-cli --init --init-email foo@bar.com uses --init as a command (i.e. tells the CLI to run the init process) and uses --init-email for config option (i.e. tells the CLI what the email is).

A more typical API would be in my opinion be something like weaviate-cli init --email foo@bar.com, whereas init would be a command, and --email a config flag that is scoped only to the init command. Commands can of course also be hierarchical, so for this issues we'd end up with (weaviate-cli sandbox create and weaviate-cli sandbox create --current)

A major benefit is that the commands are their own scopes which can also have their own help menus. For example weaviate-cli --help would print a generic help whereas weaviate-cli sandbox --help would print a sandbox-specific help.

This is a pattern that is quite common. For example If you want to retrieve the credentials from a GKE cluster with the gcloud tool, you would run gcloud container clusters get-credentials --zone europe-west1-b, whereas container is the first hierarchical command, clusters is the second and get-credentials the third. Finally, --zone=europe-west1-b is additional config option via a flag.

Now that I've written this, I realize even more how much of it's own topic this should be and I recommend creating a new issues based off of this comment. Nevertheless it would affect this design as well. (EDIT: Done, see #14)

etiennedi commented 5 years ago

Additionally I would like to suggest:

$ weaviate-cli --sandbox --create --current The --current flag means that you don't have to rerun weaviate-cli --init and that it automatically sets it as the current Weaviate.

I think the feature is a really great idea, but --current isn't the most intuitive term. I.e. just from reading the command I don't think I'd understand that this would update my config. Some alternative suggestions: