maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/pkg/workspace/settings.go

16 lines
605 B
Go
Raw Normal View History

Update the copyright end date to 2018. (#1068) Just what it says on the tin.
2018-03-21 20:43:21 +01:00
// Copyright 2016-2018, Pulumi Corporation. All rights reserved.
Begin overhauling semantic phases This change further merges the new AST and MuPack/MuIL formats and abstractions into the core of the compiler. A good amount of the old code is gone now; I decided against ripping it all out in one fell swoop so that I can methodically check that we are preserving all relevant decisions and/or functionality we had in the old model. The changes are too numerous to outline in this commit message, however, here are the noteworthy ones: * Split up the notion of symbols and tokens, resulting in: - pkg/symbols for true compiler symbols (bound nodes) - pkg/tokens for name-based tokens, identifiers, constants * Several packages move underneath pkg/compiler: - pkg/ast becomes pkg/compiler/ast - pkg/errors becomes pkg/compiler/errors - pkg/symbols becomes pkg/compiler/symbols * pkg/ast/... becomes pkg/compiler/legacy/ast/... * pkg/pack/ast becomes pkg/compiler/ast. * pkg/options goes away, merged back into pkg/compiler. * All binding functionality moves underneath a dedicated package, pkg/compiler/binder. The legacy.go file contains cruft that will eventually go away, while the other files represent a halfway point between new and old, but are expected to stay roughly in the current shape. * All parsing functionality is moved underneath a new pkg/compiler/metadata namespace, and we adopt new terminology "metadata reading" since real parsing happens in the MetaMu compilers. Hence, Parser has become metadata.Reader. * In general phases of the compiler no longer share access to the actual compiler.Compiler object. Instead, shared state is moved to the core.Context object underneath pkg/compiler/core. * Dependency resolution during binding has been rewritten to the new model, including stashing bound package symbols in the context object, and detecting import cycles. * Compiler construction does not take a workspace object. Instead, creation of a workspace is entirely hidden inside of the compiler's constructor logic. * There are three Compile* functions on the Compiler interface, to support different styles of invoking compilation: Compile() auto- detects a Mu package, based on the workspace; CompilePath(string) loads the target as a Mu package and compiles it, regardless of the workspace settings; and, CompilePackage(*pack.Package) will compile a pre-loaded package AST, again regardless of workspace. * Delete the _fe, _sema, and parsetree phases. They are no longer relevant and the functionality is largely subsumed by the above. ...and so very much more. I'm surprised I ever got this to compile again!
2017-01-18 21:18:37 +01:00
package workspace
import (
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
"github.com/pulumi/pulumi/pkg/resource/config"
Rename pulumi-fabric to pulumi This includes a few changes: * The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi. * The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi. * The CLI is renamed from lumi to pulumi.
2017-09-22 04:18:21 +02:00
"github.com/pulumi/pulumi/pkg/tokens"
Begin overhauling semantic phases This change further merges the new AST and MuPack/MuIL formats and abstractions into the core of the compiler. A good amount of the old code is gone now; I decided against ripping it all out in one fell swoop so that I can methodically check that we are preserving all relevant decisions and/or functionality we had in the old model. The changes are too numerous to outline in this commit message, however, here are the noteworthy ones: * Split up the notion of symbols and tokens, resulting in: - pkg/symbols for true compiler symbols (bound nodes) - pkg/tokens for name-based tokens, identifiers, constants * Several packages move underneath pkg/compiler: - pkg/ast becomes pkg/compiler/ast - pkg/errors becomes pkg/compiler/errors - pkg/symbols becomes pkg/compiler/symbols * pkg/ast/... becomes pkg/compiler/legacy/ast/... * pkg/pack/ast becomes pkg/compiler/ast. * pkg/options goes away, merged back into pkg/compiler. * All binding functionality moves underneath a dedicated package, pkg/compiler/binder. The legacy.go file contains cruft that will eventually go away, while the other files represent a halfway point between new and old, but are expected to stay roughly in the current shape. * All parsing functionality is moved underneath a new pkg/compiler/metadata namespace, and we adopt new terminology "metadata reading" since real parsing happens in the MetaMu compilers. Hence, Parser has become metadata.Reader. * In general phases of the compiler no longer share access to the actual compiler.Compiler object. Instead, shared state is moved to the core.Context object underneath pkg/compiler/core. * Dependency resolution during binding has been rewritten to the new model, including stashing bound package symbols in the context object, and detecting import cycles. * Compiler construction does not take a workspace object. Instead, creation of a workspace is entirely hidden inside of the compiler's constructor logic. * There are three Compile* functions on the Compiler interface, to support different styles of invoking compilation: Compile() auto- detects a Mu package, based on the workspace; CompilePath(string) loads the target as a Mu package and compiles it, regardless of the workspace settings; and, CompilePackage(*pack.Package) will compile a pre-loaded package AST, again regardless of workspace. * Delete the _fe, _sema, and parsetree phases. They are no longer relevant and the functionality is largely subsumed by the above. ...and so very much more. I'm surprised I ever got this to compile again!
2017-01-18 21:18:37 +01:00
)
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
// Settings defines workspace settings shared amongst many related projects.
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
// nolint: lll
Make major commands more pleasant This change eliminates the need to constantly type in the environment name when performing major commands like configuration, planning, and deployment. It's probably due to my age, however, I keep fat-fingering simple commands in front of investors and I am embarrassed! In the new model, there is a notion of a "current environment", and I have modeled it kinda sorta just like Git's notion of "current branch." By default, the current environment is set when you `init` something. Otherwise, there is the `coco env select <env>` command to change it. (Running this command w/out a new <env> will show you the current one.) The major commands `config`, `plan`, `deploy`, and `destroy` will prefer to use the current environment, unless it is overridden by using the --env flag. All of the `coco env <cmd> <env>` commands still require the explicit passing of an environment which seems reasonable since they are, after all, about manipulating environments. As part of this, I've overhauled the aging workspace settings cruft, which had fallen into disrepair since the initial prototype.
2017-03-22 03:23:32 +01:00
type Settings struct {
Deprecate old configuration model We are going to be changing the configuration model. To begin, let's take most of the existing stuff and mark it as "deprecated" so we can keep the existing behavior (to help transition newer code forward) while making it clear what APIs should not be called in the implementation of `pulumi` itself.
2018-02-27 00:55:25 +01:00
Stack tokens.QName `json:"stack,omitempty" yaml:"env,omitempty"` // an optional default stack to use.
ConfigDeprecated map[tokens.QName]config.Map `json:"config,omitempty" yaml:"config,omitempty"` // optional workspace local configuration (overrides values in a project)
Begin overhauling semantic phases This change further merges the new AST and MuPack/MuIL formats and abstractions into the core of the compiler. A good amount of the old code is gone now; I decided against ripping it all out in one fell swoop so that I can methodically check that we are preserving all relevant decisions and/or functionality we had in the old model. The changes are too numerous to outline in this commit message, however, here are the noteworthy ones: * Split up the notion of symbols and tokens, resulting in: - pkg/symbols for true compiler symbols (bound nodes) - pkg/tokens for name-based tokens, identifiers, constants * Several packages move underneath pkg/compiler: - pkg/ast becomes pkg/compiler/ast - pkg/errors becomes pkg/compiler/errors - pkg/symbols becomes pkg/compiler/symbols * pkg/ast/... becomes pkg/compiler/legacy/ast/... * pkg/pack/ast becomes pkg/compiler/ast. * pkg/options goes away, merged back into pkg/compiler. * All binding functionality moves underneath a dedicated package, pkg/compiler/binder. The legacy.go file contains cruft that will eventually go away, while the other files represent a halfway point between new and old, but are expected to stay roughly in the current shape. * All parsing functionality is moved underneath a new pkg/compiler/metadata namespace, and we adopt new terminology "metadata reading" since real parsing happens in the MetaMu compilers. Hence, Parser has become metadata.Reader. * In general phases of the compiler no longer share access to the actual compiler.Compiler object. Instead, shared state is moved to the core.Context object underneath pkg/compiler/core. * Dependency resolution during binding has been rewritten to the new model, including stashing bound package symbols in the context object, and detecting import cycles. * Compiler construction does not take a workspace object. Instead, creation of a workspace is entirely hidden inside of the compiler's constructor logic. * There are three Compile* functions on the Compiler interface, to support different styles of invoking compilation: Compile() auto- detects a Mu package, based on the workspace; CompilePath(string) loads the target as a Mu package and compiles it, regardless of the workspace settings; and, CompilePackage(*pack.Package) will compile a pre-loaded package AST, again regardless of workspace. * Delete the _fe, _sema, and parsetree phases. They are no longer relevant and the functionality is largely subsumed by the above. ...and so very much more. I'm surprised I ever got this to compile again!
2017-01-18 21:18:37 +01:00
}
Reference in a new issue Copy permalink