Idea #22390
Updated by Peter Amstutz 10 days ago
When @arvados-client@ is invoked as @arv@ it should mimic as much as possible the CLI of the Ruby @arv@ tool. <pre> $ arv Arvados command line client Usage: arv [--flags] subcommand|resource [method] [--parameters] Available flags: -n, --dry-run Don't actually do anything -v, --verbose Print some things on stderr -f, --format=<s> Set the output format. Must be one of json (default), yaml or uuid. (Default: json) -s, --short Return only UUIDs (equivalent to --format=uuid) Use 'arv subcommand|resource --help' to get more information about a particular command or resource. Available subcommands: copy, create, edit, get, keep, tag, ws Available resources: api_client_authorization, authorized_key, collection, computed_permission, container, container_request, group, keep_service, link, log, user, user_agreement, virtual_machine, workflow, config, vocabulary, sy Additional options: -e, --version Print version and exit -h, --help Show this message </pre> Passthrough commands: * The @copy@ subcommand just invokes the Python @arv-copy@ and can stay that way. * The @ws@ subcommand invokes @arv-ws@ which provides a live stream of events from websockets. * The @keep@ subcommand just invokes the corresponding Python tools @arv-ls@, @arv-get@, @arv-put@, or @arv-keepdocker@ * The @tag@ subcommand invokes the @arv-tag@ subcommand which is another Ruby tool. These are link-based tags, which are generally deprecated in favor of properties. Internally implemented: * The @create@ subcommand invokes an interactive text editor where the user edits JSON that will be sent as the body in a @create@ API operation for a given resource type. This is pretty simple and could be handy but I forgot it existed and can't remember the last time I used it. * The @edit@ subcommand fetches the JSON of an object, invokes an interactive text editor where the user edits the returned JSON, any fields that are changed are as the body in a @update@ API operation for a given resource type. * The @get@ subcommand takes an arbitrary UUID and list of fields to select on, determines which API endpoint to use, and prints JSON to stdout. Also simple and could be handy but I also forgot it existed. * The @keep@ subcommand just invokes the corresponding Python tools @arv-ls@, @arv-get@, @arv-put@, or @arv-keepdocker@ * The @tag@ subcommand invokes the @arv-tag@ subcommand which is another Ruby tool. These are link-based tags, which are generally deprecated in favor of properties. * The @ws@ subcommand invokes @arv-ws@ which provides a live stream of events from websockets. * The various resource commands were mechanically derived from the discovery document, so it should be possible to generate a compatible CLI Migration: * Installs an @arv@ symlink in @/usr/bin@ to @/usr/bin/arvados-client@ * Should be a drop-in replacement, any changes in behavior are a bug * Add feature to check for other @arv@ commands in the $PATH and issue a warning. * Arvados 3.1: @arvados-client@ can be used as a full replacement & update documentation telling people to use @arvados-client@ and uninstall @arvados-cli@ gem ** no new versions of "arvados-cli" are published & the code is dropped from git ** documentation includes a note about migrating @arv-tag@ to @arv link create@, also advises to install the old version if there are any regressions. Other notes: * Will be generating CLI from discovery doc. Whether this is done at runtime or compile time is left up to the implementer. * Will need to update documentation & include instructions for installing the new tool and uninstalling the old one * the "sys" resource is being incorrectly depluralized to "sy" which doesn't actually work, so we should make that work _or_ suppress it from the CLI because it's only used for internal communication between controller and rails. ** if it's easy to make it work, "why not" this is why we make APIs ** on the other hand it is rejected by controller (and thus not invokable) then it should be suppressed