Support invoking some of the subcommands without tiup

[BusyJay]

Feature Request

Is your feature request related to a problem? Please describe: For most enterprise users, they use tiup just to maintain a cluster. Most of the time, what they run are just the sub-commands of cluster components. Currently, cluster is a subcommand of tiup, it's recommended to run tiup cluster to maintain clusters according to official documents.

Always typing tiup cluster is inconvenient comparing to just typing cluster or ticluster apparently.

Describe the feature you'd like: Support installing some of the subcommands as standalone commands.

We can learn from rustup. rustup is a similar tools as tiup, but it maintains components of rust. After using rustup to install toolchains, it is not required to run rustup cargo or rustup rustc to invoke cargo or rustc. It installs rustc and cargo as standalone commands and those commands will invoke configured version at runtime.

tiup can also install frequent used subcommands like cluster and playground as standalone commands, so user can choose what they want conveniently. And tiup becomes what it actually claims itself:

tiup is a tool to download and install TiDB components.

Describe alternatives you've considered: Users can setup shell alias by themselves. It's unfriendly to users, but can solve the problem currently.

Teachability, Documentation, Adoption, Migration Strategy:

[lonng]

@BusyJay How about adding a tiup alias subcommand to create a shortcut for specific component.

1. tiup alias ticluster cluster -> shortcut to the latest version of the cluster component
2. tiup alias ticluster cluster:vN -> shortcut to the vN version of the cluster component
3. tiup install cluster --alias ticluster
4. tiup install cluster:vN --alias ticluster

Even more some subcommands of cluster component, e.g:

• tiup alias tiupgrade cluster upgrade
• tiup alias tistatus cluster display

Some flags of tiup alias

• tiup alias --list
• tiup alias --delete ticluster

Implementation:

All aliases will generate a shell script for each alias at ~/.tiup/bin/, and fill with the below content:

#!/bin/sh
tiup cluster $@

[BusyJay]

I'm OK with the implement. It would be better if the alias is set by default.

[rkazak]

common terms like 'cluster' may/will have already been taken for example

rkazak@rkazaknb tiup % ls -l $(which cluster)
lrwxr-xr-x  1 rkazak  admin  37 Mar 26 17:59 /usr/local/bin/cluster -> ../Cellar/graphviz/2.47.0/bin/cluster
rkazak@rkazaknb tiup % 

so the ti prefix should be required? so ticluster for example.

As a first pass we could, at install time, setup things such that all 'tiup <command>' have the 'ti<command>' shorten form available...

I like the alias subcommand option but it's use can be more general, for example

tiup alias installV5 'tiup install cluster:v5.0.0'

or even

tiup alias installV5 'tiinstall cluster:v5.0.0'

if nesting of aliases is workable.

The most important thing to consider is managing conflicting commands and aliases...

[rkazak]

So I had a quick look at how this could be done and I have some questions and an alternative suggestion too, but a couple of other things need to be considered;

I see the components directories have directories whose names are version numbers so would there be a need for links to executables in each of these directories? or just the latest version? ( cluster and playground components ).

../components/cluster:
v1.3.6	v1.3.7	v1.4.0

../components/grafana:
v4.0.11			v4.0.12			v5.0.0-nightly-20210326	v5.0.0-nightly-20210402

../components/pd:
v4.0.11			v4.0.12			v5.0.0-nightly-20210326	v5.0.0-nightly-20210402

../components/playground:
v1.3.6	v1.3.7	v1.4.0

../components/prometheus:
v4.0.11			v4.0.12			v5.0.0-nightly-20210326	v5.0.0-nightly-20210402

../components/tidb:
v4.0.11			v4.0.12			v5.0.0-nightly-20210326	v5.0.0-nightly-20210402

../components/tiflash:
v4.0.11			v4.0.12			v5.0.0-nightly-20210402

../components/tikv:
v4.0.11			v4.0.12			v5.0.0-nightly-20210326	v5.0.0-nightly-20210402
rkazak@rkazaknb bin % 

[rkazak]

Sorry to see that there is no input from the filer! - I think that as a first step we can just have two symlinks to implement this. We can have a link 'active' which is local to the playground and cluster directories which will point to the currently active version. Then we can create a symlink from that which points into the 'bin' directory.

So

rkazak@rkazaknb ~ % ls -al .tiup/components/cluster 
total 0
drwxr-xr-x   7 rkazak  staff  224 Apr 13 14:00 .
drwxr-xr-x  19 rkazak  staff  608 Apr  5 12:45 ..
lrwxr-xr-x   1 rkazak  staff    8 Apr  13 11:30 active -> ./v1.4.0
drwxr-xr-x   3 rkazak  staff   96 Mar 24 20:52 v1.3.6

Then in the common bin directory

rkazak@rkazaknb ~ % ls -al .tiup/bin               
total 41952
drwxr-xr-x  7 rkazak  staff       224 Apr 13 14:25 .
drwxr-xr-x  8 rkazak  staff       256 Apr 13 14:25 ..
lrwxr-xr-x  1 rkazak  staff        41 Apr  13 11:32 ticluster -> ../components/cluster/active/tiup-cluster
-rwxr-xr-x  1 rkazak  staff  21462032 Apr 13 14:25 tiup

I was just wondering how to support multiple versions? Do people revert back to older version? (I mean so do we really need that)