Historically (before there were "backends") Terraform had a single state
file format used both for real state snapshots and for tracking where
remote state was stored.
Terraform v0.12 caused these two to be split because we adopted state
snapshot version 4 for real snapshots but retained a subset of version 3
for tracking the remote backend configuration in the local working
directory.
Unfortunately we previously kept that working by retaining a snapshot of
the entire Terraform v0.11 "terraform" package as legacy/terraform, which
happened to still be around because we also needed to retain a copy of
the entire legacy SDK to keep the remote state backends working.
This now hoists just the tiny slice of legacy terraform package
functionality needed to implement the "backend state" file format into
package workdir. This package is a good home for it because it's part of
the working directory state. Ideally it would be accessed through methods
of the workdir.Dir type, but that's too disruptive a refactor to combine
into this and so that'll need to wait for another day; for now we'll keep
the existing callers doing their access through our "clistate" package
that is itself a forked snapshot of what statemgr.Filesystem used to be
in Terraform v0.11.
This removes all but one of the uses of "legacy/terraform" aside from calls
in the other packages under "legacy". We'll clean up the last one in a
later commit, because it's not related to the backend state file format.
Go 1.19's "fmt" has some awareness of the new doc comment formatting
conventions and adjusts the presentation of the source comments to make
it clearer how godoc would interpret them. Therefore this commit includes
various updates made by "go fmt" to acheve that.
In line with our usual convention that we make stylistic/grammar/spelling
tweaks typically only when we're "in the area" changing something else
anyway, I also took this opportunity to review most of the comments that
this updated to see if there were any other opportunities to improve them.
This commit replaces `ioutil.TempDir` with `t.TempDir` in tests. The
directory created by `t.TempDir` is automatically removed when the test
and all its subtests complete.
Prior to this commit, temporary directory created using `ioutil.TempDir`
needs to be removed manually by calling `os.RemoveAll`, which is omitted
in some tests. The error handling boilerplate e.g.
defer func() {
if err := os.RemoveAll(dir); err != nil {
t.Fatal(err)
}
}
is also tedious, but `t.TempDir` handles this for us nicely.
Reference: https://pkg.go.dev/testing#T.TempDir
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Thus far our various interactions with the bits of state we keep
associated with a working directory have all been implemented directly
inside the "command" package -- often in the huge command.Meta type -- and
not managed collectively via a single component.
There's too many little codepaths reading and writing from the working
directory and data directory to refactor it all in one step, but this is
an attempt at a first step towards a future where everything that reads
and writes from the current working directory would do so via an object
that encapsulates the implementation details and offers a high-level API
to read and write all of these session-persistent settings.
The design here continues our gradual path towards using a dependency
injection style where "package main" is solely responsible for directly
interacting with the OS command line, the OS environment, the OS working
directory, the stdio streams, and the CLI configuration, and then
communicating the resulting information to the rest of Terraform by wiring
together objects. It seems likely that eventually we'll have enough wiring
code in package main to justify a more explicit organization of that code,
but for this commit the new "workdir.Dir" object is just wired directly in
place of its predecessors, without any significant change of code
organization at that top layer.
This first commit focuses on the main files and directories we use to
find provider plugins, because a subsequent commit will lightly reorganize
the separation of concerns for plugin launching with a similar goal of
collecting all of the relevant logic together into one spot.
