Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update dependency to github.com/go-viper/mapstructure/v2 #290

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mikelolasagasti
Copy link

Module github.com/go-viper/mapstructure/v2 is the blessed fork for module github.com/mitchellh/mapstructure as annoucned by Mitchell Hashimoto in
https://gist.github.com/mitchellh/90029601268e59a29e64e55bab1c5bdc

Alpha version is just the module rename
go-viper/mapstructure@v1.6.0...v2.0.0-alpha.1

Module `github.com/go-viper/mapstructure/v2` is the blessed fork for
module `github.com/mitchellh/mapstructure` as annoucned by Mitchell
Hashimoto in
https://gist.github.com/mitchellh/90029601268e59a29e64e55bab1c5bdc

Alpha version is just the module rename
go-viper/mapstructure@v1.6.0...v2.0.0-alpha.1

Signed-off-by: Mikel Olasagasti Uranga <mikel@olasagasti.info>
@cipherboy
Copy link
Contributor

@mikelolasagasti what's your thoughts on removing this dependency?

@mikelolasagasti
Copy link
Author

As module github.com/mitchellh/mapstructure won't be maintained anymore and there is a blessed fork, I though it would be a good idea to adopt it for better future maintenance.

The 2.0.0-alpha1 version of the new module is just the rename of the original module.

OpenTofu accepted the PR I sent a few weeks ago.

@cipherboy
Copy link
Contributor

@mikelolasagasti Right, but I'm wondering if we'd be better off removing this dependency anyways.

I think we mostly considered its use as deprecated; there were a few places where we'd use it for compatibility, but in general, new uses should not have used it. This is especially true in the public facing APIs: we preferred explicit serialization over automatic serialization of the underlying datastructure, as it makes incremental breaking changes harder (e.g., if we change from an int -> time.Duration in the underlying datastructure, it is easier to provide request/response compatibility if we own the serialization ourselves).

This isn't about whether it'd be good to adopt this, but whether we can simplify and remove it altogether. :-) But perhaps best we adopt this in the interim and remove usage of this and github.com/fatih/structs long-term.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants