It is simply the best/simplest solution and trying to prevent users from passing and integer here would be like opening a can of worms. Because:
* we cannot make mapstructure validate our duration string ( with an UnmarshalJSON func etc.)
* we cannot make mapstructure spit a string instead of a duration and packer will decode-encode-decode config.
* the hcl2 generated code asks for a string, so this will be enforced by default.
Before this commit it was possible to set a duration using an integer or a float. Go's time.Duration is an int64 internally an mapstructure will take advantage of this and load the number as a int64 but `1` means one ns which is unexpected/confusing. To avoid confusion and enforce readability this forces users to pass a string with a unit for a duration; ex "56s".
mapstructure-to-hcl2 fills the gaps between hcl2 and mapstructure for Packer
By generating a struct that the HCL2 ecosystem understands making use of
mapstructure tags.
Packer heavily uses the mapstructure decoding library to load/parse user
config files. Packer now needs to move to HCL2.
Here are a few differences/gaps betweens hcl2 and mapstructure:
* in HCL2 all basic struct fields (string/int/struct) that are not pointers
are required ( must be set ). In mapstructure everything is optional.
* mapstructure allows to 'squash' fields
(ex: Field CommonStructType `mapstructure:",squash"`) this allows to
decorate structs and reuse configuration code. HCL2 parsing libs don't have
anything similar.
mapstructure-to-hcl2 will parse Packer's config files and generate the HCL2
compliant code that will allow to not change any of the current builders in
order to move to HCL2 to softly move to HCL2.
Adrien Delorme
Megan Marsh