Packer: Accept YAML for configuration to support code comments

[mcandre]

Debugging boot_command steps is quite painful without the ability to easily label different sections with code comments, or even toggle steps on and off with comments. Could packer provide a way to accept YAML configurations instead of JSON?

[rickard-von-essen]

Duplicates #1047

See https://github.com/hashicorp/packer/issues/4200#issuecomment-262584432

[edward2a]

@rickard-von-essen @mitchellh @mwhooker guys, just a thought, the HCL support has been mentioned for years now, and there is a sample implementation of YAML as you acknowledged here: https://github.com/hashicorp/packer/issues/5744

ref #4200 for visibility

Why not just take a bit of time to add this and make our (user's) life easier until HCL is supported, which at least myself, I'm not looking forward for given the lack off official HCL parsers for different languages.

I don't believe a template pre-processor can be avoided at all given different use cases (I fetch config items from a remote system and generate the template from a yaml), but certainly JSON is not my friend, and HCL support does not fit my use case easily.

[vtolstov]

some years ago i'm already provide pr to support yaml transparently (it converts inside packer yaml to struct like json), but packer team does not want to merge it.
https://github.com/hashicorp/packer/pull/4461

@rickard-von-essen or other devs, may be its time to bring this up again as hcl/hcl2 not in packer for years?

[edward2a]

@vtolstov that sets another precedent that it can be done with not much effort.

I have nothing against HCL, but as mentioned, not yet supported and also lack of official libraries for different languages is not encouraging. In fact, I understand that so far, HCL has been a Hashicorp only data model and wonder whether if pushing in that direction does not actually hinder adoption of the tools in a way.

I don't believe anybody sane would trade HCL for JSON for writing stuff in, for example, terraform, but HCL for YAML not only is relatively pain free, many other popular products in the industry use YAML and or adopted it in the recent years (K8s, GCDS, CFN).

@cbednarski made a comment on documentation effort, which I believe is very valid, but I would argue that given the compatibility of the structures between JSON and YAML it may not be necessary to actually write such examples or any other information than 'YAML is supported'.

[SwampDragons]

I know that the length of time the HCL issue has been open has caused a lot of cynicism, but it's on our internal roadmap planned for v1.5.0 (probably septemberish 2019) and we have done a lot of thinking and preliminary work on it.

If you want to make or work off a fork of Packer that supports yaml in the meantime, you're welcome to do so, but I still don't want to support the extra config language. I'm sorry. We only have two full-time engineers on Packer and the potential long tail of support questions for adding another config language -- even when the initial PR is fairly straightforward-- is just too much for us to manage.

[edward2a]

Alright, will try to ge that done. http://alt-packer.co

I was hoping it would not come to that, hopefully we will not end like RSS or that poster from CNCF.

I do not understand why the term 'cynicism' is invoked in relation to requesting an industry standard data model.
Hashicorp has created some very nice tools and an ecosystem around it, that's great, but this kind of attitude gives me the feeling that the intention is to keep the products clean and within the ecosystem (as per the support for vault and consul inside packer). If that's the case, find with it :+1:

Furthermore, I insist on the remark of lack of official HCL parsers for other languages.

Thanks for your time and patience!

[SwampDragons]

I think I might have been unclear. When I said “cynicism” I was thinking about about folks thinking we were never going to actually get around to implementing HCL; I wasn’t talking about YAML

[SwampDragons]

Well, that was an unfortunate phone autocorrect. (YAML --> y'all in my previous comment. Edited to clarify on the github comment.) 🤦‍♀️

For what it's worth, I promise we are not trying to keep Packer inside some kind of HashiCorp walled garden. The entire philosophy of the company is that we make lots of different tools and you can use one of them or all of them, and we're happy either way. We pride ourselves on being able to "play nice" with other tools. That said, it does make sense to try to keep the tools somewhat consistent with each other so that if people _do_ want to use more than one then it's not too hard to do so. That's part of where the motivation to support HCL comes in; a big number of Packer users also use Terraform, and vice versa. Having the tools support the same paradigm is a win for those users.

Anyway, thanks for being understanding. I'll bring up the HCL parser question internally, because I think it is a good point.

[azr]

Hello there, I wanted to add a few things on top of what @SwampDragons said:

• HCL2 is still very fresh and terraform 0.12 ( which is using it ) has reached beta stage only very recently: https://www.hashicorp.com/blog/announcing-terraform-0-1-2-beta1 and I think we can start being optimistic about HCL2's future 🙂but these things take time generally.
• one could use yq to transform yaml to json and pass it to packer on the fly :

❯ cat buildfile.yaml | yq . | packer build -

• I am very eager to see packer start using hcl2 ! 🙂

[mcandre]

I take it back. It's not that packer needs to support YAML. It's that as a society we need to ignore Crockford and establish that JSON gets to have comments. So many man months wasted on developing alternative syntaxes when we could have done this in the first place!

Anyway, either HCL or YAML would be okay for packer. I'm skeptical that HCL is worth it, but at least it features comments, something JSON don't have.

[notzippy]

The easy button : https://github.com/spf13/viper

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.