marckhouzam
commented
1 year ago I've prototyped Option 1 with the real table printer and I'm not impressed with what I get.
Using a comma and a space as a separator. Notice the line-wrapping that happens when the column would pass 80 characters. From what I can see, this wrapping is not configurable at the moment, but we could add that configuration option to the tanzu-plugin-runtime API.
$ tz plugin search --list-versions
NAME TARGET AVAILABLE VERSIONS
builder global v0.1.0-dev-8-g6087ea00, v0.80.2, v0.81.1, v0.82.5-alpha.0, v0.89.1, v0.89.2,
v0.89.3, v0.89.4, v0.89.5, v0.89.6, v0.89.7, v0.89.8, v0.90.0-alpha.0
isolated-cluster global v0.28.0, v0.28.1
pinniped-auth global v0.25.0, v0.25.4, v0.28.0, v0.28.1
test global v0.1.0-dev-8-g6087ea00, v0.80.2, v0.81.1, v0.82.5-alpha.0, v0.89.1,
v0.90.0-alpha.0
accelerator kubernetes v1.4.0
apps kubernetes v0.10.0
cluster kubernetes v0.25.0, v0.25.4, v0.28.0, v0.28.1
feature kubernetes v0.25.0, v0.25.4, v0.28.0, v0.28.1
insight kubernetes v1.4.2
kubernetes-release kubernetes v0.25.0, v0.25.4, v0.28.0, v0.28.1
management-cluster kubernetes v0.25.0, v0.25.4, v0.28.0, v0.28.1
package kubernetes v0.25.0, v0.25.4, v0.28.0, v0.28.1
secret kubernetes v0.25.0, v0.25.4, v0.28.0, v0.28.1
services kubernetes v0.5.0
telemetry kubernetes v0.25.0, v0.25.4, v0.28.0, v0.28.1
account mission-control v0.0.1
apply mission-control v0.0.1
audit mission-control v0.0.1Although I find the wrapping to look pretty good, it will make greping for a specific plugin and its version much more difficult.
If we improve the API for table printing and turn off wrapping, we don't get a poor experience because the table printer makes every line have the same length, by padding it with spaces. This means that if one line wraps in the terminal, then all other lines will also wrap but using empty spaces, which makes it look poorly in the terminal. Here is a screenshot, as I cannot reproduce the wrapping in github text:
anujc25
Describe the feature request
The
plugin searchcommand is used to find available plugins that a user can install. The output of the command includes the latest version available. However there is currently no way to know if and which older versions of a plugin are also available for installation.Using a specific version of a plugin can be important as such a version can be required by the currently installed Tanzu product.
On the other hand, we expect users to make use of plugin groups to install the proper versions of their plugins and very rarely have to manually install an older version found through
plugin search. Therefore, the ability to list all available versions of a plugin is more for completeness than for common usage.The next section shows different options I have considered. As presented below, I prefer option 1 for the following reasons:
plugin searchcannot take a plugin name as an argument as we plan to use the argument as a filterplugin searchI don't find it is necessary to include it in the version output and helps avoid too much line wrapping.Please see the "Further alternative" section for an slightly more involved alternative which I'm actually leaning towards.
Describe alternative(s) you've considered
Reminder of the current basic command:
Option 1: List all versions in a list, no description field to provide more space
Option 2: Option 1 but with description field
Option 3: One version per line
Option 4: One plugin at a time using a different flag and argument
Option 4.1: Option 4 in column format
Option 5: Like option 4 but more future-proof due to more generic flag name
Option 5 can evolve to things like:
Further alternative
Note that we could take a slightly different approach if we allow
tanzu plugin searchto take a plugin name as an argument. This would have multiple benefits (examples follow):--list-versionsflag, which would be replaced by specifying the plugin nameNote that a filtering feature can still be provided but using a flag
-f/--filter. Examples of such an approach:Basic command (unchanged):
Details of a single plugin:
Using a filter