Make deployment-related commands configurable

[itowlson]

At the moment, spin deploy and spin login are aliases for the spin cloud plugin equivalents. This is partly for backward compatibility (the Cloud code used to be in Spin itself) and partly for discoverability (users can see there is a deployment command without needing to install a plugin first). We should break that mapping so that the open Spin CLI has no specific awareness of/ties to the Cloud plugin.

One option is to remove the aliases altogether, but I think the discoverability argument still hold water.

So I propose instead to keep the aliases but move them over to being user-configured. That is, the user would choose which plugin they aliased to.

Implementation

There are various ways to do this:

1. General purpose aliases - that is, the user could alias any string to a command, possibly with options. This would be more onerous for setting up deploy and login, but would allow other common patterns to be aliased too (e.g. alias bup to build --up)

2. Environment variable giving the plugin name e.g. export SPIN_DEPLOYMENT_PLUGIN=cloud. The deploy and login commands (only) would consult this value. This would require users to go into things like .profile or Windows Control Panel to set them up. On the other hand EVs are a very standard thing that developers and ops folk know how to manage.

3. Global (and local?) config via command a la Git, e.g. spin config add deployment-plugin cloud, This would provide a space for other config to go in future, but is very Spin-specific. Perhaps such a thing would ultimately unify with an alias system anyway.

Probably others too, open to suggestions!

Process

This is a breaking change. We must be very respectful of users' existing workflow, and must give them time and opportunity to migrate to the new way when it is convenient for them before force the change. My conservative suggestion is:

• 3.2: implement the chosen configuration system, available for those who want it, maintainer testing, communicate plan and timeframe
• 3.3: add advisory message to deploy and login guiding users to get ready and configure them
• 3.4: upgrade message to a yellow exclamation warning
• 3.5-3.x: stronger red skull-and-crossbones warning, remove cloud plugin from installer linked in Spin docs (retain auto install for now). To consider: interrupt flow in interatcive environments to prompt for configuration if the implementation is suitable?
• 4.0: BREAKING: unconfigured deploy and login are errors, message guides users to find plugins, remove auto Cloud install

However, we may want to compress this in order to address concerns about the existing coupling, or if 4.0 is closer than anticipated. E.g. show the deprecation advisory or even yellow warning in 3.2.

Assistance and guidance

Helping the users find the right plugin for them could be a challenge, and we don't want to leave them unsupported. We could consider doing some Spin Hub work in parallel to allow the CLI to present users with a list of known deployment plugins. However we should assess whether linking Spin directly to the Hub was acceptable given that decoupling is the motive!

[karthik2804]

A couple of potential pathways for knowing about keeping track of deployment plugins:

• We could modify the plugin manifest to contain a type field that can be used to filter suitable plugins
• We could also maintain a separate list alongside the plugins that can then be referred to for deployment plugins.