-
-
Notifications
You must be signed in to change notification settings - Fork 530
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
Custom UnmarshalTOML() decoded keys left in meta.Undecoded() #425
Comments
mvo5
added a commit
to mvo5/images
that referenced
this issue
Sep 24, 2024
The current toml filesytem customizations will decode a `FilesystemCustomization` as a map[string]interface{}. This means that the underlying toml engine will not konw what keys inside the map are decoded and which are not decoded. This lead to the issue osbuild/bootc-image-builder#655 in `bootc-image-builder` where we check if we have unencoded entries and if so error (in this case incorrectly). This commit fixes the issue by moving the toml decoding from the struct/map[string]interface{} to primitive types. It's a bit ugly as is (partly because of the limited go type system) but with that the tests pass and len(meta.Undecoded()) is the expected zero. I opened BurntSushi/toml#425 to see if there is another way via a custom unmarshaler.
mvo5
added a commit
to mvo5/toml
that referenced
this issue
Sep 24, 2024
This commit adds a failing test for the scenario decribed in issue BurntSushi#425
mvo5
added a commit
to mvo5/images
that referenced
this issue
Sep 24, 2024
The current toml filesytem customizations will decode a `FilesystemCustomization` as a map[string]interface{}. This means that the underlying toml engine will not konw what keys inside the map are decoded and which are not decoded. This lead to the issue osbuild/bootc-image-builder#655 in `bootc-image-builder` where we check if we have unencoded entries and if so error (in this case incorrectly). This commit fixes the issue by moving the toml decoding from the struct/map[string]interface{} to primitive types. It's a bit ugly as is (partly because of the limited go type system) but with that the tests pass and len(meta.Undecoded()) is the expected zero. I opened BurntSushi/toml#425 to see if there is another way via a custom unmarshaler.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First, thanks your amazing library!
It looks like when doing a custom UnmarshalTOML() for a struct this will leave the keys decoded there in meta.Undecoded().
Here is a minimal test case:
and the output:
Our use-case is very similar [0], we want to dynamically handle int or string sizes in the toml.
I think we can fix this particular issue via moving decoding to primitive types and not structs
but it would be nice to have a way in UnmarshalTOML() for complex types to signal to the
MetaData object that certain keys are decoded (or maybe this exists and I just couldn't
figure it out)?
[0] https://github.com/osbuild/images/blob/main/pkg/blueprint/filesystem_customizations.go#L27
The text was updated successfully, but these errors were encountered: