pulumi/cmd/plugin_install.go

232 lines
7.6 KiB
Go
Raw Normal View History

2018-05-22 21:43:36 +02:00
// Copyright 2016-2018, Pulumi Corporation.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
package cmd
import (
"fmt"
"io"
"os"
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
"github.com/blang/semver"
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
"github.com/cheggaaa/pb"
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
"github.com/pkg/errors"
"github.com/spf13/cobra"
"github.com/pulumi/pulumi/pkg/backend/display"
"github.com/pulumi/pulumi/pkg/diag"
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
"github.com/pulumi/pulumi/pkg/diag/colors"
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
"github.com/pulumi/pulumi/pkg/util/cmdutil"
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
"github.com/pulumi/pulumi/pkg/util/contract"
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
"github.com/pulumi/pulumi/pkg/workspace"
)
func newPluginInstallCmd() *cobra.Command {
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
var serverURL string
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
var cloudURL string
var exact bool
var file string
var reinstall bool
var verbose bool
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
var cmd = &cobra.Command{
Use: "install [KIND NAME VERSION]",
Args: cmdutil.MaximumNArgs(3),
Short: "Install one or more plugins",
Long: "Install one or more plugins.\n" +
"\n" +
"This command is used manually install plugins required by your program. It may\n" +
"be run either with a specific KIND, NAME, and VERSION, or by omitting these and\n" +
"letting Pulumi compute the set of plugins that may be required by the current\n" +
"project. VERSION cannot be a range: it must be a specific number.\n" +
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
"\n" +
"If you let Pulumi compute the set to download, it is conservative and may end up\n" +
"downloading more plugins than is strictly necessary.",
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
displayOpts := display.Options{
Color: cmdutil.GetGlobalColorization(),
}
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
if serverURL != "" && cloudURL != "" {
return errors.New("only one of server and cloud-url may be specified")
}
if cloudURL != "" {
cmdutil.Diag().Warningf(diag.Message("", "cloud-url is deprecated, please pass '--server "+
"%s/releases/plugins' instead."), cloudURL)
serverURL = cloudURL + "/releases/plugins"
}
// Note we don't presently set this as the default value for `--server` so we can play games like the above
// where we want to ensure at most one of `--server` or `--cloud-url` is set.
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
if serverURL == "" {
serverURL = "https://api.pulumi.com/releases/plugins"
}
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
// Parse the kind, name, and version, if specified.
var installs []workspace.PluginInfo
if len(args) > 0 {
if !workspace.IsPluginKind(args[0]) {
return errors.Errorf("unrecognized plugin kind: %s", args[0])
} else if len(args) < 2 {
return errors.New("missing plugin name argument")
} else if len(args) < 3 {
return errors.New("missing plugin version argument")
}
version, err := semver.ParseTolerant(args[2])
if err != nil {
return errors.Wrap(err, "invalid plugin semver")
}
installs = append(installs, workspace.PluginInfo{
Kind: workspace.PluginKind(args[0]),
Name: args[1],
Version: &version,
ServerURL: serverURL,
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
})
} else {
if file != "" {
return errors.New("--file (-f) is only valid if a specific package is being installed")
}
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
// If a specific plugin wasn't given, compute the set of plugins the current project needs.
plugins, err := getProjectPlugins()
if err != nil {
return err
}
for _, plugin := range plugins {
// Skip language plugins; by definition, we already have one installed.
// TODO[pulumi/pulumi#956]: eventually we will want to honor and install these in the usual way.
if plugin.Kind != workspace.LanguagePlugin {
installs = append(installs, plugin)
}
}
}
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
// Now for each kind, name, version pair, download it from the release website, and install it.
for _, install := range installs {
label := fmt.Sprintf("[%s plugin %s]", install.Kind, install)
cmdutil.Diag().Infoerrf(
diag.Message("", "%s installing"), label)
// If the plugin already exists, don't download it unless --reinstall was passed. Note that
// by default we accept plugins with >= constraints, unless --exact was passed which requires ==.
if !reinstall {
if exact {
if workspace.HasPlugin(install) {
if verbose {
cmdutil.Diag().Infoerrf(
diag.Message("", "%s skipping install (existing == match)"), label)
}
continue
}
} else {
if has, _ := workspace.HasPluginGTE(install); has {
if verbose {
cmdutil.Diag().Infoerrf(
diag.Message("", "%s skipping install (existing >= match)"), label)
}
continue
}
}
}
// If we got here, actually try to do the download.
var source string
var tarball io.ReadCloser
var err error
if file == "" {
if verbose {
cmdutil.Diag().Infoerrf(
diag.Message("", "%s downloading from %s"), label, install.ServerURL)
}
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
var size int64
if tarball, size, err = install.Download(); err != nil {
return errors.Wrapf(err, "%s downloading from %s", label, install.ServerURL)
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
}
// If we know the length of the download, show a progress bar.
if size != -1 {
bar := pb.New(int(size))
tarball = newBarProxyReadCloser(bar, tarball)
bar.Prefix(displayOpts.Color.Colorize(colors.SpecUnimportant + "Downloading plugin: "))
bar.Postfix(displayOpts.Color.Colorize(colors.Reset))
bar.SetMaxWidth(80)
bar.SetUnits(pb.U_BYTES)
bar.Start()
}
} else {
source = file
if verbose {
cmdutil.Diag().Infoerrf(
diag.Message("", "%s opening tarball from %s"), label, file)
}
if tarball, err = os.Open(file); err != nil {
return errors.Wrapf(err, "opening file %s", source)
}
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
}
if verbose {
cmdutil.Diag().Infoerrf(
diag.Message("", "%s installing tarball ..."), label)
}
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
if err = install.Install(tarball); err != nil {
return errors.Wrapf(err, "installing %s from %s", label, source)
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
}
}
return nil
}),
}
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
cmd.PersistentFlags().StringVar(&serverURL,
"server", "", "A URL to download plugins from")
cmd.PersistentFlags().StringVarP(&cloudURL,
"cloud-url", "c", "", "A cloud URL to download releases from")
cmd.PersistentFlags().BoolVar(&exact,
"exact", false, "Force installation of an exact version match (usually >= is accepted)")
cmd.PersistentFlags().StringVarP(&file,
"file", "f", "", "Install a plugin from a tarball file, instead of downloading it")
cmd.PersistentFlags().BoolVar(&reinstall,
"reinstall", false, "Reinstall a plugin even if it already exists")
cmd.PersistentFlags().BoolVar(&verbose,
"verbose", false, "Print detailed information about the installation steps")
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
// We are moving away from supporting this option, for now we mark it hidden.
contract.AssertNoError(cmd.PersistentFlags().MarkHidden("cloud-url"))
Implement basic plugin management This change implements basic plugin management, but we do not yet actually use the plugins for anything (that comes next). Plugins are stored in `~/.pulumi/plugins`, and are expected to be in the format `pulumi-<KIND>-<NAME>-v<VERSION>[.exe]`. The KIND is one of `analyzer`, `language`, or `resource`, the NAME is a hyphen- delimited name (e.g., `aws` or `foo-bar`), and VERSION is the plugin's semantic version (e.g., `0.9.11`, `1.3.7-beta.a736cf`, etc). This commit includes four new CLI commands: * `pulumi plugin` is the top-level plugin command. It does nothing but show the help text for associated child commands. * `pulumi plugin install` can be used to install plugins manually. If run with no additional arguments, it will compute the set of plugins used by the current project, and download them all. It may be run to explicitly download a single plugin, however, by invoking it as `pulumi plugin install KIND NAME VERSION`. For example, `pulumi plugin install resource aws v0.9.11`. By default, this command uses the cloud backend in the usual way to perform the download, although a separate URL may be given with --cloud-url, just like all other commands that interact with our backend service. * `pulumi plugin ls` lists all plugins currently installed in the plugin cache. It displays some useful statistics, like the size of the plugin, when it was installed, when it was last used, and so on. It sorts the display alphabetically by plugin name, and for plugins with multiple versions, it shows the newest at the top. The command also summarizes how much disk space is currently being consumed by the plugin cache. There are no filtering capabilities yet. * `pulumi plugin prune` will delete plugins from the cache. By default, when run with no arguments, it will delete everything. It may be run with additional arguments, KIND, NAME, and VERSION, each one getting more specific about what it will delete. For instance, `pulumi plugin prune resource aws` will delete all AWS plugin versions, while `pulumi plugin prune resource aws <0.9` will delete all AWS plugins before version 0.9. Unless --yes is passed, the command will confirm the deletion with a count of how many plugins will be affected by the command. We do not yet actually download plugins on demand yet. That will come in a subsequent change.
2018-02-04 19:51:29 +01:00
return cmd
}
Add `--server` to `pulumi plugin install` Previously, when the CLI wanted to install a plugin, it used a special method, `DownloadPlugin` on the `httpstate` backend to actually fetch the tarball that had the plugin. The reason for this is largely tied to history, at one point during a closed beta, we required presenting an API key to download plugins (as a way to enforce folks outside the beta could not download them) and because of that it was natural to bake that functionality into the part of the code that interfaced with the rest of the API from the Pulumi Service. The downside here is that it means we need to host all the plugins on `api.pulumi.com` which prevents community folks from being able to easily write resource providers, since they have to manually manage the process of downloading a provider to a machine and getting it on the `$PATH` or putting it in the plugin cache. To make this easier, we add a `--server` argument you can pass to `pulumi plugin install` to control the URL that it attempts to fetch the tarball from. We still have perscriptive guidence on how the tarball must be named (`pulumi-[<type>]-[<provider-name>]-vX.Y.Z.tar.gz`) but the base URL can now be configured. Folks publishing packages can use install scripts to run `pulumi plugin install` passing a custom `--server` argument, if needed. There are two improvements we can make to provide a nicer end to end story here: - We can augment the GetRequiredPlugins method on the language provider to also return information about an optional server to use when downloading the provider. - We can pass information about a server to download plugins from as part of a resource registration or creation of a first class provider. These help out in cases where for one reason or another where `pulumi plugin install` doesn't get run before an update takes place and would allow us to either do the right thing ahead of time or provide better error messages with the correct `--server` argument. But, for now, this unblocks a majority of the cases we care about and provides a path forward for folks that want to develop and host their own resource providers.
2019-05-30 22:56:55 +02:00
// barCloser is an implementation of io.Closer that finishes a progress bar upon Close() as well as closing its
// underlying readCloser.
type barCloser struct {
bar *pb.ProgressBar
readCloser io.ReadCloser
}
func (bc *barCloser) Read(dest []byte) (int, error) {
return bc.readCloser.Read(dest)
}
func (bc *barCloser) Close() error {
bc.bar.Finish()
return bc.readCloser.Close()
}
func newBarProxyReadCloser(bar *pb.ProgressBar, r io.Reader) io.ReadCloser {
return &barCloser{
bar: bar,
readCloser: bar.NewProxyReader(r),
}
}