spf13 / viper

Go configuration with fangs
MIT License
27.12k stars 2.02k forks source link

Make hashicorp/hcl dependency optional or remove #1608

Open superchalupa opened 1 year ago

superchalupa commented 1 year ago

Preflight Checklist

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[bot] commented 1 year ago

👋 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 https://github.com/spf13/viper/issues/1046 (any progress?) I don't see what problem this issue tries to address.

RainbowMango commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 9 months ago

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 https://github.com/spf13/viper/issues/540).

toddbaert commented 5 months ago

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

sagikazarmark commented 5 months ago

1.20 is going to introduce a LOT of changes (already got rid of a lot of dependencies from the core). I'm doing my best to make this happen in that release as well.

sagikazarmark commented 4 months ago

v1.20.0-alpha.3 removes HCL as a dependency. Please give it a try.

If all goes well, I'll release v1.20.0 somewhere around mid July.

yesudeep commented 3 months ago

Please consider adding a check in the CI using https://github.com/google/go-licenses to prevent issues with licensing as well if something like that isn't already there.

yesudeep commented 3 months ago

v1.20.0-alpha.3 removes HCL as a dependency. Please give it a try.

If all goes well, I'll release v1.20.0 somewhere around mid July.

Namaste @sagikazarmark do you still expect to make this release soon?

majestix508 commented 3 weeks ago

@sagikazarmark Hi, when can we expect the v1.20.0 release? 3 month have passed since...

sagikazarmark commented 2 weeks ago

@yesudeep @majestix508 The latest alpha has been running in production @openmeterio for weeks. Feel free to give that a try.

I need to write an upgrade guide before I can tag a release to ensure a smooth migration.