PartialContent documentation mismatch with behavior? about hcl HOT 4 CLOSED

Hi @yardbirdsax,

If I'm understanding correctly it seems like you are studying the implementation details of hclsyntax.Body and trying to make use of its internals.

All of the hcl.Body implementations are intended to be used only with the hcl.Body interface API, with the implementation then adapting from that standard API to something private that makes sense for a particular kind of body. Those internal details are not part of the public API, but if the externally-visible behavior (without inspecting the internals) doesn't match what's documented then that might be a bug.

You've not shared code but from your description I'm guessing you've written something similar to the following:

content, remain, diags := body.Content(/* ... */)
// ...
attrs, diags := remain.JustAttributes()
// ...

If the above does match the essence of what you wrote then indeed the expected behavior would be that attrs would include only the attributes that were not already consumed by the first call to Content. It's up to each body implementation to decide how to achieve that abstraction, but that's the behavior required for any correct implementation. If that's not the behavior you observed then that does seem like a bug, but it would be helpful to see the code you wrote that demonstrates the misbehavior concretely so that we can make sure to fix the bug you have encountered, rather than some other unrelated misbehavior.

from hcl.

Hi @apparentlymart ,

Thanks for the comment! What you described is mostly accurate in terms of my intentions. Let me try and describe why I resorted to using the low level hclsyntax.Body type.

I have a block of arbitrary HCL code which includes one or more nested blocks and attributes, like this:

resource "something_some_resource" "something" {
  attribute = "something"
  block {
    block_attribute = "something"
  }
}

For this, I want to retrieve only the attributes and their values; I do not care about the blocks in any way. I do not, however, know what the attributes or nested blocks are ahead of time, so cannot construct a schema and use Content(/*...*/) to parse them directly, nor PartialContent(/*...*/).

Basically, I'd like to achieve what JustAttributes() does, except minus this bit. I suppose I could just ignore the diagnostics, since that is the only error that it returns, but I'm not sure if that's guaranteed to remain that way, no? (Based on this, it's already not the expected behavior.)

from hcl.

Hi @yardbirdsax,

As a general rule HCL does assume you know ahead of time what schema is expected, and that characteristic is an important part of how HCL's JSON variant can make sense of what would otherwise be an ambiguous structure: the JSON equivalent of the Terraform configuration you showed would only be able to differentiate between "block" being a block type or an attribute by referring to the schema.

The HCL API therefore isn't really designed to achieve what you want to achieve here; there is no generic "just give me everything and I'll decide what to do with it" API.

There are a few options here:

• Decide ahead of time the subset of the resource type schema that is relevant to your specific goal and write that explicitly in your code. Use PartialContent to ignore everything else, and just discard the "remain" body altogether.
• Use terraform providers schema -json to get the schema information for the providers you are interested in and translate that into an HCL-level schema. The Terraform provider schema model is at a higher level of abstraction than HCL's but this translation is effectively what Terraform itself is doing to decode these, albeit using an in-memory form of the schema instead of the JSON export format.
• Bypass the syntax-agnostic API altogether and instead limit your program to only supporting the HCL "native syntax" as implemented in package hclsyntax. If you type-assert your body to the specific body type in that package then you can work directly with the fields it exposes, but at the expense of not being able to support other syntaxes like the JSON syntax.
• If your goal is configuration modification rather than just configuration loading, the hclwrite package API might be helpful, although that is also specific to the native syntax.

from hcl.

D'oh! I realized I never came back to say "Thanks, this is good information and I think I'm good to go!" 🤦 Now I've said it, I'll close the issue.

from hcl.