Make hashicorp/hcl dependency optional or remove

[superchalupa]

Preflight Checklist

• I have searched the issue tracker for an issue that matches the one I want to file, without success.
• I am not looking for support or already pursued the available support channels without success.
• I have checked the troubleshooting guide for my problem, without success.

Viper Version

1.16

Go Version

1.20

Config Source

Files

Format

JSON, YAML

Repl.it link

No response

Code reproducing the issue

No response

Expected Behavior

Expected behavior is that my module does not grow indirect dependencies on hashicorp libraries, as they have announced that they are no longer open source.

Actual Behavior

Actual behavior is that my module has a dependency on hasicorp/hcl. This is undesirable.

Steps To Reproduce

1. start a project that imports spf13/viper
2. initialize your module (go mod init)
3. examine go.mod and see: go.mod: github.com/hashicorp/hcl v1.0.0 // indirect

Additional Information

Hashicorp has announced that they are no longer open source friendly. https://www.hashicorp.com/license-faq

Viper has a dependency on github.com/hashicorp/hcl. If my project uses viper, then my go.mod will include an #indirect dependency on hashicorp/hcl. While this library appears to still be under MPL, the scrutiny on any projects that include hashicorp code is intense and we are under pressure to remove any dependencies on hashicorp libraries.

Can we remove, refactor, or otherwise make this dependency optional? It appears to be used only by github.com/spf13/viper/internal/encoding/hcl/codec.go

[github-actions]

👋 Thanks for reporting!

A maintainer will take a look at your issue shortly. 👀

In the meantime: We are working on Viper v2 and we would love to hear your thoughts about what you like or don't like about Viper, so we can improve or fix those issues.

⏰ If you have a couple minutes, please take some time and share your thoughts: https://forms.gle/R6faU74qPRPAzchZ9

📣 If you've already given us your feedback, you can still help by spreading the news,
either by sharing the above link or telling people about this on Twitter:

https://twitter.com/sagikazarmark/status/1306904078967074816

Thank you! ❤️

[sagikazarmark]

In the long term, the HCL dependency is going away.

In the short term, we can probably put some built tag guards in the code to ensure HCL never-ever gets compiled into the resulting binary, but it's still going to show up in your go.mod file as an indirect dependency.

go.mod and go.sum are not indicative of what gets compiled into the final binary. Unfortunately, most tooling are poorly written in this regard, resulting in lots of false positive findings when it comes to Go dependencies.

If the above short term solution works for you, I can make that happen.

[RainbowMango]

In the short term, we can probably put some built tag guards in the code to ensure HCL never-ever gets compiled into the resulting binary, but it's still going to show up in your go.mod file as an indirect dependency.

It doesn't work I guess, just because the HCL still presents as an indirect dependency, which is concerning.

By the way, here is an example, of how the dependency affects down stream project :), (You don't need to reproduce it)

[andig]

I still fail to understand the actual problem (though I'm not concerned, so please forgive me):

HashiCorp APIs, SDKs, and almost all other libraries will remain MPL 2.0.

Meaning: no change. While I support the idea of trimming the dependencies and especially #1046 (any progress?) I don't see what problem this issue tries to address.

[RainbowMango]

While this library appears to still be under MPL, the scrutiny on any projects that include hashicorp code is intense and we are under pressure to remove any dependencies on hashicorp libraries.

Echo from the issue description.
@andig I can feel that as long as a project uses anything from Harshicorp, it will be challenged.

[sagikazarmark]

I'm inclined to make an exception to that backwards compatibility rule here and just drop the HCL codec from the mainline Viper package, but there needs to be an option to add it back.

Give me some time to come up with a solution.

[fabriziopandini]

This will be great!
As said above, if a project uses anything from Harshicorp, it will be challenged as we are in Cluster API (In CAPI we are happy users of Viper!)

[sagikazarmark]

@RainbowMango just out of curiosity: Is the HCL package the only one you would like to see gone? How about the consul API package which is another dependency of Viper? (That one is probably much harder to get rid of and would require a new major version)

[RainbowMango]

For us, yes, since this is the only HCS package that is present in our dependencies. For the consul API package, we don't use it to build our components even though it is present in go.sum.

[ncabanis]

We really appreciate your useful library. As a vendor of commercial software, we cannot use it, as long as this component or any indirect dependency forces use to disclose source code, which HCL with its MPL license does (see also #540).

[toddbaert]

It would be great to have this removed! Thanks so much in any case for this great software.