In OpenTofu's current design, the "version" argument in a "module" block
is reserved for use only by the module registry protocol. Directly
specifying a remote source address does not allow that argument because
it delegates the installation process to go-getter, which has no concept
of versioning.
Therefore we'll start by following the existing precedent from existing
source address syntaxes like the one we use for Git repositories, where
the tag or digest is selected using URL query-string-style syntax.
In a later version of OpenTofu we might move to support "version" for
some of the remote source address syntaxes, at least including the "oci"
and "git" protocols. However, such a change is not in scope for the OCI
registry project because it would likely require a wholesale replacement
of go-getter with an API that better resembles our module registry client
API.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This commit rescopes what was originally a draft about provider
installation from OCI registries into a more general document about how
we intend to use OCI container images and OCI registries as a distribution
vehicle for at least two different kinds of OpenTofu dependency packages
(module and provider packages).
This document already had good content about how OCI registries and
artifacts work _in general_, and its associated PR was already attracting
general discussion about whether to use Docker-style or ORAS-style
conventions across both provider and module packages, so we'll now use
this document to discuss just the overall question of what style of
packaging we intend to use (across both package types) and will discuss
the module-specific and provider-specific details in other RFCs.
This also reworks the document to now propose using the Docker-like
conventions instead of the ORAS-like conventions, since that matches what
we've been exploring in prototypes. Of course, that decision is not final
until this RFC is accepted and merged, but we have considerably better
understanding of how this would work under the Docker-like approach than
ORAS and it seems like consensus is so far heading in that direction. We
may revise this document again if we learn of some strong arguments in
favor of the ORAS approach.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
We seem to have inherited an incomplete implementation of something from
the predecessor project here: a "tofu cloud" command that just tries to
immediately delegate any invocation to another executable called
"terraform-cloudplugin" in the current working directory, used as a
go-plugin style plugin.
This has some TODO comments suggesting that it was intended to change to
download a plugin from some remote place before executing it, but our
stubby version doesn't do that. I was also hidden behind an experimental
feature guard and so has never been accessible in any released version of
OpenTofu; we don't currently produce any releases with experimental
features enabled.
Therefore this commit just deletes it so that we don't have this dead code
to potentially worry about. Perhaps one day we'll offer some extension
point for adding extra subcommands through plugins, but if we do that then
we'll presumably design our own mechanism for doing it rather than
extending this dead code that was added for reasons unknown to us.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This selects the latest version of Go for forthcoming releases.
Upgrading does immediately change some behaviors, which are documented in
the CHANGELOG.md update here.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
In a future commit we will adopt golangci-lint v1.64.5, which now triggers
lint warnings for some code that was previously not detected. This commit
is the smallest change to address those differences.
Unfortunately the "cloud" package and the "remote" backend both rely on
non-idiomatic error message formatting because they emit the returned error
message text directly into the UI, so to avoid changing the UI output but
also avoid significant refactoring this just adds nolint comments to those
for now. A future commit might address this by reworking things so that
the UI takes care of its own presentation concerns instead of relying on
the main implementation to directly generate UI-appropriate error strings.
This also completely disables the exportloopref linter, because that was
for a loop scoping hazard that was already addressed by a language change
in Go 1.22. This linter is therefore completely removed in newer versions
of golangci-lint and would thus generate an error if left enabled after
upgrading.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This fixes a problem with the "stringer" tool that breaks our "go generate"
process after upgrading to Go 1.24.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Go 1.24 introduces stricter checks for format string validation.
This commit fixes instances where non-constant format strings were
used in calls to functions like `fmt.Errorf`, `fmt.Printf`, and similar.
Changes include:
- Replacing dynamically constructed strings passed as format strings
with constant format strings.
- Refactoring `fmt.Sprintf` calls to ensure the format string matches
the number of arguments provided.
- Simplifying redundant formatting and ensuring compliance with Go
1.24's stricter `vet` tool checks.
This update ensures compatibility with Go 1.24 and prevents potential
runtime errors caused by misinterpreted dynamic format strings.
Resolves#2389
Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Although we don't promise that OpenTofu will work well with more than a
few hundred resource instances in a particular configuration, we know that
some people do use it that way and they sometimes find and share
opportunities for improving performance due to those opportunities being
easier to spot at large scale.
These two benchmarks aim to help us measure improvements that affect the
pure overhead of the core language runtime, without any real provider calls
and without the CLI layer's contributions, so that we can more easily
compare before and after of changes when we're either trying to understand
a reported performance regression or we're trying out potential performance
improvements.
As noted in the comments inline, the presence of these benchmarks is not
intended to represent a commitment to support using OpenTofu outside of its
design assumptions, but they will hopefully help us continue our current
best-effort approach to reducing overhead where we can do so without risk
to existing functionality, increasing maintenance overhead, or making it
harder to introduce new features over time.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
A lot of our testing utilities were written before the introduction of the
testing.TB interface that represents what *testing.T and *testing.B have
in common, and those that weren't have followed precedent from those that
were in directly expecting *testing.T.
Using testing.TB instead makes these helpers usable from both normal tests
and testing benchmark functions, since they only use methods that are
available in both contexts.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This function was previously quite long and complex, so this commit splits
it into a number of smaller functions.
The previous code structure was made more awkward by having to work around
all being together in one function -- particularly the part iterating over
the values used in an expression -- and so the new layout is quite
different and thus the diff is hard to read. However, there are
intentionally no test changes in this commit to help us be confident that
this has not regressed anything, and the existing unit tests for this
component seem quite comprehensive.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This function's cyclomatic complexity is essentially just a count of the
number of conditions in the test, which are written out as a flat sequence
of "if" statements and so cannot really be simplified any more without
making the test harder to read and maintain overall.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
Our complexity lint rules previously considered this function to have both
too many statements and too many lines.
Factoring out more of the "single-attr ref" logic into the
parseSingleAttrRef function eliminated one statement per case that was
using it.
Factoring out the handling of module call references -- the most complex
case this function handles -- into a separate parseModuleCallRef reduced
it considerably more.
Removing the empty lines between the "case" statements was necessary after
that just to get below the line count limit, which seems like a rather
dubious situation for a lint rule to complain about but it doesn't seem
to hurt readability, so fair enough.
The rework of parseSingleAttrRef made it slightly less convenient to use
as part of parseModuleCallRef, but not onerously so and thus this
prioritizes making the common case simpler at the expense of a small
amount of extra work in the parseModuleCallRef function.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
