Use JSON instead of TOML as config format

[owenthereal]

As discussed in this thread, we'll standardize the JSON format of the config file to something like:

{
    "Deps": [
        {
            "ImportPath": "rsc.io/arm/armasm",
            "Rev": "616aea947362"
        },
        {
            "ImportPath": "rsc.io/x86/x86asm",
            "Rev": "af2970a7819d"
        }
    ]
}

[elithrar]

Have you also considered lowercasing the "Nut.toml" filename? I'm not sure if it matters, but having all lower-case aligns with Go's file naming conventions and should probably be documented as such too.

I'd also argue that TOML is a much nicer format for hand-editing over JSON. If there's any expectation that users (humans) touch this file in any way, I think TOML makes more sense.

[lithammer]

I'd also argue that TOML is a much nicer format for hand-editing over JSON. If there's any expectation that users (humans) touch this file in any way, I think TOML makes more sense.

I think one of the reasons for choosing JSON is that it doesn't require any external dependencies like TOML does. So unless a TOML parser makes its way into the standard library I don't think it'll happen.

On the other hand, I guess nut could support both and have TOML support as a differentiator against other dependency managers. And supply a "compile-to-standard-config-format" command if you'd for some reason would like to move to another dependency manager.

Just suggestions and speculation though.

[owenthereal]

@elithrar:

I'd also argue that TOML is a much nicer format for hand-editing over JSON. If there's any expectation that users (humans) touch this file in any way, I think TOML makes more sense.

I personally like TOML over JSON as well. But as you read from the discussions linked in issue, we're trying to standardize the config file format across the Go community, e.g., Godep will use the same format. The suggestion is to use something that the Go standard library can parse. This leaves us to options like JSON or Go itself. It seems no conclusion has been made yet. Feel free to comment on the discussion thread to show your concerns. I voted TOML BTW :smile:.

Have you also considered lowercasing the "Nut.toml" filename?

This will be standardized as part of the discussion too.

[owenthereal]

@renstrom:

I guess nut could support both and have TOML support as a differentiator against other dependency managers. And supply a "compile-to-standard-config-format" command if you'd for some reason would like to move to another dependency manager.

I thought about this too. But I don't have enough facts to prove it to be a good idea yet. If we were to go with this approach, I'm thinking keeping Nut.toml the same, but running nut install will generate the standardized config file in ./internal/TBDCONFIG.CFG. It's like Ruby Bundler generating a Gemfile.lock from Gemfile. Nut.toml is less strict about defining the versions of the dependencies, e.g., leaving it blank to always get the latest dependencies as it's today. But ./internal/TBDCONFIG.CFG will be ultimate source of truth for dependencies' versions.