| # Experimental plugins |
| |
| When developing a new plugin, the experimental (or 'work in progress') nature of |
| the work is indicated by marking the plugin as experimental. |
| |
| ## Mark a plugin as experimental |
| |
| When defining a plugin function within the plugin lib.rs file, there will be an |
| entry point decorated with `ffx_plugin` such as: |
| |
| ``` |
| #[ffx_plugin()] |
| ``` |
| |
| or |
| |
| ``` |
| #[ffx_plugin(MyProxy = "fuchsia.example.Service")] |
| ``` |
| |
| To mark a plugin as experimental and simultaneously declare the token used to |
| enable the experiment, add an initial string parameter. In the following example |
| the tag "zippy" may (or may not) match the plugin command name. The label may be |
| arbitrary, but it's recommended to choose a value that relates to the plugin: |
| |
| ``` |
| #[ffx_plugin("zippy")] |
| ``` |
| |
| or |
| |
| ``` |
| #[ffx_plugin("zippy", MyProxy = "fuchsia.example.Service")] |
| ``` |
| |
| In both examples above, the plugin will be guarded by a feature token named |
| "zippy". When users try to execute `ffx zippy` they will be informed that zippy |
| is experimental, then instructions for enabling the zippy feature will be shown. |
| |
| After following the instructions to enable zippy, future calls (for that user) |
| will operate as if zippy were not experimental, i.e. they have opted-in to using |
| the zippy feature. |
