When checking module registry credentials .tofurc is ignored

[rlees85]

Describe the bug

When checking module registry credentials .tofurc is ignored however .terraformrc is not. Obviously this is a small bug with a very simple workaround but I am raising it as Terragrunt would appear to be backing OpenTofu.

Workaround:

Configure .terraformrc instead.

Steps To Reproduce

• Have a private Terraform module registry (unfortunately this is not straightforward but if you have a Gitlab account you are in luck!)
• Configure your .tofurc file with the registry's access token
• Terragrunt is unable to pull the module.

Expected behavior

For Terragrunt to be able to download the module given the token provided in .tofurc.

Must haves

• Steps for reproduction provided.

Nice to haves

• Terminal output
• Screenshots

Versions

• Terragrunt version: 0.90.0
• OpenTofu/Terraform version: 1.10.6 (not relevant, doesn't get as far as invoking Tofu)
• Environment details (Ubuntu 20.04, Windows 10, etc.): Archlinux

Additional context

I believe the problem lies in this file: https://github.com/gruntwork-io/terragrunt/blob/main/tf/cliconfig/user_config.go
Due to this dependency: github.com/hashicorp/terraform/command/cliconfig

This may be an easy fix as long as https://github.com/opentofu/opentofu/tree/main/internal/command/cliconfig is available as a Go package.

I may pick this up in my own time but I am just raising the issue for now so it can at least be tracked.

[yhakbar]

Hey @rlees85 ,

Unfortunately, that internal package won't be available as a direct dependency due to being in an internal directory.

Placing code in an internal directory is how Golang authors signal to external consumers that the code isn't intended to be stable for consumption by third-parties, and you can't import the code from another repository when it's in an internal directory. We might have to vendor the files (basically copy them into a Terragrunt internal/vendored/opentofu/internal/command/cliconfig directory) to enable usage of that code as a Golang package. We'll want to make sure that we document why we are vendoring this code, and a call-out that we likely want to stop vendoring it if the underlying code becomes exported as a first-class library. We'll also want to make sure that the appropriate license headers are preserved to signal that we're not claiming ownership of that code, and do all the right things from an IP perspective. This might also get really complicated if we have to vendor a ton of content from the repository for this to work, so we have to be cautious here.

Alternatively, we could also just hack around this limitation by temporarily creating a copy of the .tofurc file with the name .terraformrc, and only support capabilities that are backwards compatible with .terraformrc until there comes a time when a public library is exported for this kind of thing (if that ever happens, which isn't guaranteed).

Note that there's an open issue discussing this kind of thing in the OpenTofu repo here: opentofu/opentofu#3059. The decision to choose whether or not to make any OpenTofu code accessible to third parties is something that's entirely an OpenTofu decision, and it goes without saying that the decision should be in the best interest of the OpenTofu project. Exposing functionality like this as libraries does result in additional burden to maintainers, as they have increased responsibility to control breaking changes to the library (which they won't incur if they keep the code internal).