remove TOML and JSON support? about task HOT 15 CLOSED

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.

from task.

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.

from task.

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

from task.

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

from task.

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.

from task.

I also just use yaml.

from task.

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

from task.

Done on master branch

from task.

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

from task.

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.

from task.

@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.

from task.

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

from task.

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

from task.

@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...

from task.

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

from task.