This follows on from conversations with @fibonacci1729 and @tschneidereit (who came up with more of these ideas than I did!).
Right now the target environments system is the proverbial ambulance at the bottom of the cliff - it can tell you that your code won't run where you want to run it, but that's all.
But if we centred target environments in the application creation workflow, they could act as a hub for the stuff you need to successfully build for that environment. The specific ideas we've discussed are:
-
A target environment could point to a set of templates that are known to work in that environment. For example, suppose that Bob's Discount Cloud supports only WAGI. Then running spin new -E bdc@latest would offer you a selection of sparkling WAGI templates with none of your new-fangled component model nonsense.
-
A target environment could contain a list of plugins that are required to work with the environment. For example, suppose you need the bobcloud plugin to deploy to or manage applications on Bob's Discount Cloud. Then spin new -E bdc@latest could check if the bobcloud plugin is installed, and if not install it from the plugins registry.
(Note that the latter is a significant and possibly surprising new behaviour of the spin new command. spin new has previously confined its antics to the application directory: now it would be installing software on your machine. We would want to ensure that the user was clearly informed and felt that they had consented.)
This would set the user up so that 1. the application was guaranteed to work in the environment and 2. they had the tools necessary to get it up and running there.
I did a POC if the 'target environment templates' idea and it appeared to work, but it was only a POC - there are several questions left to explore. The plugins idea should be fairly simple provided we have a good solution to the informed consent aspect.
This follows on from conversations with @fibonacci1729 and @tschneidereit (who came up with more of these ideas than I did!).
Right now the target environments system is the proverbial ambulance at the bottom of the cliff - it can tell you that your code won't run where you want to run it, but that's all.
But if we centred target environments in the application creation workflow, they could act as a hub for the stuff you need to successfully build for that environment. The specific ideas we've discussed are:
A target environment could point to a set of templates that are known to work in that environment. For example, suppose that Bob's Discount Cloud supports only WAGI. Then running
spin new -E bdc@latestwould offer you a selection of sparkling WAGI templates with none of your new-fangled component model nonsense.A target environment could contain a list of plugins that are required to work with the environment. For example, suppose you need the
bobcloudplugin to deploy to or manage applications on Bob's Discount Cloud. Thenspin new -E bdc@latestcould check if thebobcloudplugin is installed, and if not install it from the plugins registry.(Note that the latter is a significant and possibly surprising new behaviour of the
spin newcommand.spin newhas previously confined its antics to the application directory: now it would be installing software on your machine. We would want to ensure that the user was clearly informed and felt that they had consented.)This would set the user up so that 1. the application was guaranteed to work in the environment and 2. they had the tools necessary to get it up and running there.
I did a POC if the 'target environment templates' idea and it appeared to work, but it was only a POC - there are several questions left to explore. The plugins idea should be fairly simple provided we have a good solution to the informed consent aspect.