8 Commits (a15a4acf2f0e4e8a749d9cb9a46ac09f224d5e90)

Author	SHA1	Message	Date
Martin Atkins	f77e7a61b0	various: helpers for collecting necessary provider types ... Since schemas are required to interpret provider, resource, and provisioner attributes in configs, states, and plans, these helpers intend to make it easier to gather up the the necessary provider types in order to preload all of the needed schemas before beginning further processing. Config.ProviderTypes returns directly the list of provider types, since at this level further detail is not useful: we've not yet run the provider allocation algorithm, and so the only thing we can reliably extract here is provider types themselves. State.ProviderAddrs and Plan.ProviderAddrs each return a list of absolute provider addresses, which can then be turned into a list of provider types using the new helper providers.AddressedTypesAbs. Since we're already using configs.Config throughout core, this also updates the terraform.LoadSchemas helper to use Config.ProviderTypes to find the necessary providers, rather than implementing its own discovery logic. states.State is not yet plumbed in, so we cannot yet use State.ProviderAddrs to deal with the state but there's a TODO comment to remind us to update that in a later commit when we swap out terraform.State for states.State. A later commit will probably refactor this further so that we can easily obtain schema for the providers needed to interpret a plan too, but that is deferred here because further work is required to make core work with the new plan types first. At that point, terraform.LoadSchemas may become providers.LoadSchemas with a different interface that just accepts lists of provider and provisioner names that have been gathered by the caller using these new helpers.	8 years ago
Martin Atkins	2eba023537	configs: NewEmptyConfig function ... This is useful for creating a valid placeholder configuration, but not much else. Most callers should use BuildConfig to build a configuration that actually has something in it.	8 years ago
Martin Atkins	cd51864d84	configs: Start using the new "addrs" package types for modules ... We initially just mimicked our old practice of using []string for module paths here, but the addrs package now gives us a pair of types that better capture the two different kinds of module addresses we are dealing with: static addresses (nodes in the configuration tree) and dynamic/instance addresses (which can represent the situation where multiple instances are created from a single module call). This distinction still remains rather artificial since we don't yet have support for count or for_each on module calls, but this is intended to lay the foundations for that to be added later, and in the mean time just gives us some handy helper functions for parsing and formatting these address types.	8 years ago
Martin Atkins	ebafa51723	command: Various updates for the new backend package API ... This is a rather-messy, complex change to get the "command" package building again against the new backend API that was updated for the new configuration loader. A lot of this is mechanical rewriting to the new API, but meta_config.go and meta_backend.go in particular saw some major changes to interface with the new loader APIs and to deal with the change in order of steps in the backend API.	8 years ago
Martin Atkins	72ad927c4d	configs/configload: package for loading configurations ... Previously the behavior for loading and installing modules was included in the same package as the representation of the module tree (in the config/module package). In our new world, the model of a module tree (now called a "Config") is included in "configs" along with the Module and File structs. This new package replaces the loading and installation functionality previously in config/module with new equivalents that work with the model objects in "configs". As of this commit, only the loading functionality is implemented. The installation functionality will follow in subsequent commits.	8 years ago
Martin Atkins	9153bb448e	configs: include the module call source range in our module tree	8 years ago
Martin Atkins	8929eca405	configs: BuildConfig function ... BuildConfig creates a module tree by recursively walking through module calls in the root module and any descendent modules. This is intended to be used both for the simple case of loading already-installed modules and the more complex case of installing modules inside "terraform init", both of which will be dealt with in a separate package.	8 years ago
Martin Atkins	13fa73c63e	configs: stub out main configuration structs ... These types represent the individual elements within configuration, the modules a configuration is made of, and the configuration (static module tree) itself.	8 years ago