What happened to include?

[jeteve]

Hi,

I'm looking at https://github.com/hashicorp/hcl2/blob/master/ext/include/doc.go and I'm wondering where this is gone?

It would be very convenient to have this in HCL. Is it coming back somehow in the future?

Thanks!

J.

[apparentlymart]

Hi @jeteve,

The packages under "ext" are "extensions" which applications can optionally use in their own HCL-based languages. For example, Terraform uses the "dynblock" extension as part of its language.

HCL started as my personal project "ZCL", which is where that "include" extension originated. HashiCorp forked my repository as the starting point for HCL 2, but then deleted various parts that no HashiCorp product needed, and so I guess that extension must have been deleted as part of that, since code that nobody is using is a liability.

If you'd like to use it in your own project's HCL-based language, you could either import it from my ZCL repository (although I'm not actively maintaining it right now, since I work at HashiCorp and so I don't really have much interest in doing essentially the same type of work in my spare time) or you could copy it from my codebase into your repository and then maintain your own fork. Unlike HashiCorp's fork, my repository is MIT licensed and so you can copy it without inheriting the weak copyleft license in this repository, as long as you bring a copy of the license into your codebase along with it.

Since it's an extension -- and therefore implemented in terms of HCL's public API rather than in terms of HCL's implementation details -- it should be possible to combine upstream HCL with your own copy of that code and get the same result as you would've got by having it in the HCL repository. (Though if you do use my copy instead of HashiCorp's then you'll of course need to change all of the zcl references to hcl instead, since the two implementations are distinct.)

I would caution that I don't actually remember what state that code was in when I last touched it. It might be incomplete or buggy.

[jeteve]

Hi @apparentlymart thanks a lot for your reply, very informative!

Thing is, I'm trying to find a nice way to re-use bits of config in my nomad jobs.

I had a look at nomad-pack that has provision for including bits of config in job definitions, but the way it deals with variables is not really convenient for me ( see hashicorp/nomad-pack#487 ).

I'm a bit reluctant to implement a home-made templating on top of nomad jobs just for the sake of including other file. I'm looking for a native way of doing this, and I feel that including the 'include' extension in the nomad main code would benefit not just me, but others with similar requests.

[apparentlymart]

Hi @jeteve,

If your main motivation is something in Nomad's language then I suggest opening a feature request about your use-case in the relevant Nomad repository. HCL is a toolkit for building languages rather than a language itself; Nomad's languages are implemented in the Nomad codebase.

The Nomad team might decide to meet that feature request by adding something similar to this old import extension, or they might have other ideas that feel more "Nomad-like", but either way the discussion should start with the relevant Nomad team and they could propose changes to HCL, or more likely just implement something for this in Nomad itself, to meet the request.

This sort of thing must be handled at the application level rather than at the HCL level (even if the application implements it with the help of an extension library here) because different applications have different needs in this area. For example, Terraform has its own idea of "modules" which have far more semantic weight in the Terraform language than simply dumping a bunch of blocks from one body onto another, and so "include" would not be appropriate for Terraform, even if it is appropriate for Nomad.