Allow overriding installation directory for `tanzu` CLI plugins

[nrb]

Describe the feature request

Currently, the tanzu CLI only looks in ${XDG_HOME} for plugins, and this location is hardcoded.

For developers iterating on plugins, this means that versions in their local clone will overwrite or conflict with installed GA plugins; only one version of a given plugin can exist on a system at any time.

Ideally, the location for plugins would be configurable, but keep the current default of ${XDG_HOME}. This way, developers can keep GA releases of plugins on their system, as well as in-development binaries.

This has the following benefits:

• By having access to both GA and development builds, differences in behavior can more easily be tested, rather than require a full uninstall and reinstall
• Development versions of plugins can more easily be validated against a different version of the tanzu CLI for forward- and backward-compatibility
• The developer's "inner loop" doesn't interfere with their ability to stand up GA clusters.

Describe alternatives you've considered

A few possibilities I can think of for implementation:

• Provide a command line argument or environment variable that's specific to tanzu to choose a directory
• Use an option within the .config/tanzu configuration files to specify the directory to look in, and ensure that tanzu can be pointed at different configuration files.
• Provide a build time argument that embeds the plugin directory inside a given tanzu binary. This is a less flexible option.
• Add $PATH-like resolution to tanzu when looking up plugins. A challenge I see with this is that the plugins listed earlier would always "win", and switching back and forth would require either changing an environment variable or config file just as the above recommendations. A benefit I see is that downstreams of tanzu-framework could use their own directories for their plugins, allowing for isolation but risking sprawl across the filesystem.

Affected product area (please put an X in all that apply)

• [ ] APIs
• [ ] Addons
• [x] CLI
• [ ] Docs
• [x] Installation
• [x] Plugin
• [ ] Security
• [ ] Test and Release
• [ ] User Experience

Additional context

This request mostly comes out of my own frustration in testing GA builds then going back to my own development versions. Having to completely wipe out my installations each time adds time to my inner loop. However, I think the solution to that particular annoyance also provides other benefits for developers and users.

[pbarker]

This is definitely a problem we want to solve. I'm thinking on how this will map into the context aware work, which changes how plugins are stored locally.

Context-aware plugins will need to be namespaced by likely both their repository and version.

Let me try and walk through a use case:

Cluster A has foo plugin at v1.2 Cluster B has foo plugin at v0.9

When I login to Cluster A I want to execute against the v1.2 binary, and if I switch to login to Cluster B I need to execute against the v0.9 binary.

This means we'll need to store these plugins locally as tanzu.repo.com/foo/v1.2 and tanzu.repo.com/foo/v0.9 with a map for the servers on which plugins to use.

With this in mind, I wonder how it may affect our approach to the problem. Could we have a different repo space for local plugins e.g. local/foo/v1.2 or maybe use versions tanzu.repo.com/foo/v1.2-dev?

[giri-varma]

Prefer the local/foo/v1.2 approach since -dev could be used as a pre-release version.

[zjs]

I wonder if (hidden?) --plugin-root and --config-root flags that take directories — with corresponding env vars or config settings — could help with this?

[nrb]

@pbarker Thanks for mentioning the repo space aspect, I honestly didn't think about that. I was more thinking about where things landed on the local machine after install, but it's totally possible that one might want to have a dev vs GA repo configuration as well.

@zjs I think that's reasonable, yes. I'm not sure if we want a full env/config/arg hierarchy for this particular feature, but a config setting that is context-aware like Patrick is mentioning sounds like a good middle ground.

[nrb]

Reviewing the Homebrew script for installing TCE, this is more important than I first realized.

When Homebrew installs a package, it creates a child process that is sandboxed only to /usr/local/Cellar/tce/, and cannot access the user's home directory. @seemiller's implementation writes out an install.sh to the Cellar directory and asks the user to run it before plugins can be used.

We should allow plugins to be located within /usr/local/tce/* so that Homebrew and other package managers can work as they're expected to.