This is a GCC-like behavior where we preproces the argument vector by
trying to treat any argument starting with "@" as a placeholder for
arguments loaded from a given filename.
As with GCC, if the remainder of the string cannot be used as a filename
to open and read, the original argument is retained literally. However,
if it _is_ possible to open and read a file of the given name then we
take that as sufficient evidence of the operator's intent to read from
that file and will fail with an error message if the file contents are not
acceptable syntax.
This uses the same upstream library as we've already been using for the
TF_CLI_ARGS... environment variables. Since main.go was quite overcrowded
with various different concerns, the handling of those environment
variables also moves into the new arguments.go file here, since the two
share an upstream dependency and both involve simplistic substitutions and
insertions into the argument vector. The observable behavior of the
environment variable handling should not be changed in any way by this
commit.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is another step towards breaking the huge functions in this package
into smaller parts that have a clearer set of inputs and outputs.
For the moment the goal is to modify the existing code as little as
possible to make this easier to review, and so the new function
tryInstallPackageFromCacheDir has an unfortunately-large number of
arguments. Future refactoring can hopefully improve on this further.
One significant change to the structure of this code is that because it's
now in a separate function working on only one provider at a time we can
rely on early return for error handling, letting the caller be responsible
for collecting any errors into the "errs" map, and so we don't need quite
as much nesting as the previous code had.
This should not change the observable behavior in any way, which is
reinforced by there being no changes to any tests in this commit.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This function has grown very large over time as the provider installation
requirements got more complicated. This is a first level of decomposition
of the three main steps into one separate function each.
The "ensureProviderVersionsInstall" method remains too large itself, but
for now that has just acquired a nolint directive so that we can approach
this gradually in the interests of making it easier to review.
This should not change the observable behavior of the provider installer
in any way, which is reinforced by the fact that there are no test changes
in this commit.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This includes a number of small enhancements and bug fixes compared to
version v1.14.4 that we were previously using, as described in this
commit's CHANGELOG update.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is a lightweight RFC proposing that we adopt some cross-cutting naming
conventions for variables of various different types whose names all
include the noun "context", both to gradually improve existing confusion
and inconsistency in the codebase and in particular to un-squat the name
"ctx" that has emerged as the idiomatic name for a context.Context
elsewhere in the Go ecosystem.
This proposal does not call for any immediate code changes. It is only an
attempt to agree on some conventions to follow in future work on other
projects.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Proposal for creating a separate "tracking issue" for each accepted RFC,
which represents the implementation of the features described in that RFC
separately from the potentially-many feature request issues it aims to
address.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Unlike the other nesting modes, we need to use some quite different code
for comparing object-backed vs. map-backed blocks, which are both possible
interpretations of the NestingMap mode depending on whether the inner
block type has any dynamically-typed attributes.
Therefore we split that case into two parts depending on what type kind
we find, so that each of the parts can then be shaped more like the other
type-specific variants of assertNestedBlockCompatible. (This also removes
one level of if nesting to placate the nestif linter.)
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This function starts with a general part that deals with conditions that
are common to all types, but then dispatches into different codepaths
depending on the type kind.
To keep the main function shorter, here we decompose the type-kind-specific
handling into separate functions, making assertValueCompatible now end
with a simpler dispatch table.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The main function is now just a jump table into a separate function for
each nesting mode. The observable behavior is unchanged.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This splits out the handling of individual attributes and individual nested
block types into separate functions, thereby reducing the length and
complexity of the top-level function.
As of this commit, assertNestedBlockCompatible is still too long to pass
our current function length linting limit, but we'll address that in a
later commit to avoid changing too much at once.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Passing the result of fmt.Sprintf as the format string to path.NewErrorf
is redundant. It can also potentially cause problems if the result would
also contain formatting verbs, although in this case the input is under
this function's full control so this was just a waste of time rather than
a behavior problem.
Go error strings also conventionally start with lowercase letters and act
as sentence fragments rather than full sentences, so the prefix used for
a zero-length path is now "root object" instead of "Root object".
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
Signed-off-by: James Humphries <james@james-humphries.co.uk>
Co-authored-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
This commit adds the definitions of provider protocol 5.6, 5.7, 6.6, and
6.7 to our archive of the historical protocol versions and then adopts
5.7 as the current version of major version 5 and 6.7 as the current
version of major version 6.
These MPL-licensed schema definitions are from the plugin protocol server
implementation in this repository, copyright HashiCorp:
https://github.com/hashicorp/terraform-plugin-go
The only modifications made are to change the "option go_package" directive
to match where the stubs need to be generated for OpenTofu, and to claim
copyright for that change and thus make the copyright header consistent
with what our pre-commit rules require.
The regeneration of the Go API stubs for the two major protocol versions
introduces some new fields and messages that OpenTofu does not yet support
but will happily ignore. Future work might make some use of these new
additions, but that's out of scope of this change that is intended only
to synchronize our protocol definition with what new plugin server releases
are likely to be linked against.
This commit continues the existing precedent of having the stubs for the
newly-added interface methods in package grpcwrap being just a panicking
stub, which is how they will remain until a future project begins using
those methods in a way which requires them to be implemented, since
implementing the wrappers would require a deeper understanding of the
desired behavior of those methods.
It appears that we previously accepted a pull request to correct a typo
that originated in the older versions of the upstream protocol definitions,
but I have intentionally not forward-ported that here because it seems
clearer to keep these definitions as close as possible to their source
of truth from upstream, given that our current intention is to follow the
protocol as documented and not to change it.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Signed-off-by: Jon Johnson <jon.johnson@chainguard.dev>
Signed-off-by: Jon Johnson <jonjohnsonjr@gmail.com>
Co-authored-by: Oleksandr Levchenkov <ollevche@gmail.com>
This function was previously failing the nestif lint rule. Factoring the
loop body out into a separate function avoids that problem and also
subjectively makes this easier to follow by separating the functional-style
enhanceFunctionDiag from the mutation of the backing array of the caller's
diags slice.
This also transforms enhanceFunctionDiags into a package-level function
rather than a method of Scope, since in practice it doesn't actually use
anything from Scope.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Whichever function were responsible for instantiating this map would
inevitably end up scaling in length based on the number of funtions and
thus violate the function length linter.
As a compromise, we'll factor out the function table into its own function
that is exempt from that linter but focused only on constructing the base
function table, and then Scope.Functions can be shorter by dealing only
with the scope-specific customizations of the returned table.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is an assortment of small changes to fix all of the remaining lint
failures in this package, based on our current golangci-lint configuration.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This function was too long for our function length linting rule, so we'll
split each of the type kinds with special handling into their own function
and thus the main typeString function is just a straightforward dispatch
table with only one statement per case.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This value was too long for our function length lint rule, and factoring
out the printing of null values makes this more balanced with how we're
already handling unknown values and sensitive values so that the main
body of FormatValue is focused on the normal value printing case.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The functions in these files are for handling older state snapshot formats
that current OpenTofu versions never generate, and so it's highly unlikely
that we'll ever make substantial changes to these functions.
Therefore it's unjustified to risk reworking it to pass linting rules, and
so we'll add nolint comments instead. Our priority is to make as few
changes as possible to these functions, to minimize the risk of regressing
a upgrade paths that are exercised very infrequently.
(For context, state version 4 has been current ever since Terraform
v0.12.0, and so the earlier versions are long obsolete.)
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>