remove TOML and JSON support?

[andreynering]

Maintaining different formats is getting complicated after #32, specially with TOML, that is a very inflexible format.

This was asked long ago, but I don't think anyone are actually using it.

I'm asking here if anyone have a problem with it first.

/cc @tscholl2 @sascha-andres @smyrman @zbindenren

[tscholl2]

I'm not using this, but I think it's great people are still working on it. So if you drop TOML/JSON then it doesn't bother me. Thanks for asking though!

Also I looked at the issue you mentioned. I wasn't sure if this would work, but could you just unmarshal a json file, then marshal it into a yaml string, then unmarshal it using the custom yaml unmarshaler? I might be misunderstanding what's involved though, I didn't read that closely.

[smyrman]

I don't have a problem with TOML support, or even JSON, being dropped.

[sascha-andres]

I tend to use YAML everywhere as I personally like expressiveness and structure a log. Therefore it would not bother me.

Besides I think supporting one thing right is a better approach as opposed to make it work for everyone ( TOML, JSON and YAML ) with limitations due to the lowest common features.

[andreynering]

Thanks for the feedback. I'll drop them soon in the next release, so this don't block us in new features and refactorings.

[smyrman]

Just to reply @tscholl2

Also I looked at the issue you mentioned. I wasn't sure if this would work, but could you just unmarshal a json file, then marshal it into a yaml string, then unmarshal it using the custom yaml unmarshaler? I might be misunderstanding what's involved though, I didn't read that closely.

You probably could do that, but it's probably somewhat error prone. Another option could be to have an UnmarshalJSON(data []byte) error implementation for the type(s) that needs it that does the following:

1. Validates correct JSON, and maybe replace all tabs with two spaces.
2. Calls UnmarshalYAML(data []byte) error with the sanitised data.

Most JSON (unless perhaps if it's indented by tabs) will be considered valid YAML. However, this still leads to having to support two formats.

[zbindenren]

I also just use yaml.

[zbindenren]

Travis-ci and gitlab-ci only have yaml support. So I think people are quite familiar with it.

[andreynering]

Done on master branch

[earthboundkid]

Oh no! I use TOML. Is it too late to switch back? 😢

[andreynering]

I'm sorry for that @carlmjohnson

I know backward incompatible changes are a pain, and I usually thought well before doing them.

Unfortunally TOML and JSON are not as full featured as YAML, and we don't plan to support other formats soon.

You can convert your files to YAML to keep using Task.

[runeimp]

@carlmjohnson Checkout Remarshal to get help you get started on the conversion. I rather like TOML for simple config bit agree that YAML is much better for enhancing task.

[earthboundkid]

I ended up converting my TOML to YAML with Remarshall on my own, but thanks for the advice. 😄

[earthboundkid]

BTW, you can see my Taskfile linked in my blog post: https://blog.carlmjohnson.net/post/2017/hugo-asset-pipeline/

[andreynering]

@carlmjohnson I saw your article and added it to the README.

Just more info about why I prefer YAML for Task (in case someone else comes to this issue):

• You can easily write multiline string. In YAML we have the pipe operator |, but on JSON you'd have to add uglies \n
• You can break big non-multiline string in multiple lines
• TOML in very inflexible, and don't allow much customization in the Go side
• JSON disallow comments
• etc...

[runeimp]

@carlmjohnson Yeah, didn't realize your comment was almost two weeks old before I posted. BTW, nice article! ;-)