Move the CLI into its own crate

[vkleen]

Move the Nickel CLI into its own crate nickel-lang-cli. This will make it easier to integrate external tools such as Topiary without incurring a ton of dependencies in the nickel-lang crate.

In the future, we may want to split out the REPL handling from nickel-lang into the CLI, and the WASM interface. But for now, this PR is just a straightforward move.

[yannham]

I think there several things to consider. How that will play with the next update? For example, people updating the nickel-lang package via cargo, thinking they will just have the latest version of the binary, will find an error saying something like "there's no binary available" I guess? I wonder how we could smooth the transition.

Second, It's not horrible but it's a bit sad to split the test in two (mainly because the source code controlling error messages are not in the CLI crate currently, but thinking about it, maybe they should just be? I don't really know the answer at this point)

[vkleen]

The error message formatting itself should probably stay accessible from the nickel-lang crate. For example, the Python bindings report an error message as a string and I'd expect people embedding Nickel wouldn't want to reimplement the formatting for errors every time. But splitting the tests is a bit sad. I think the problem is that there are really two interwoven components that the snapshot tests are testing. One is the CLI interface with export, etc., and their interaction with pretty printing and error reporting; an end-to-end integration test in a way. The other component is the error message printing itself and the format of the error messages.

I suppose we could split the snapshot tests by purpose, but I'm not sure the effort would be worth it at the moment.

[yannham]

I wonder also if we shouldn't move everything ito its own subdirectory, including the nickel-lang crate, and name directories accordingly, so that the hierarchy is more consistent. Also, we might have to update the README or other documentation lying around about running tests, since there's now tests located inside two different crates.

[vkleen]

I like the idea of nickel-lang living in its own subdirectory as well. The last commit does that and fixes the associated test failures. I'll have a look at the READMEs next.

[yannham]

@vkleen is it ready for review? Last time I checked there were still some mixed up stuff with nickel-lang, nickel-lang-cli and nickel-lang-lib

[vkleen]

I think it's ready for review now. Hopefully I've found all the mixups 😅

[yannham]

I'm still not 100% sure about the nickel-lang vs nickel-lang-cli 😅 but I guess if we want to change that for the next release, it's just a small search and replace, isn't it? It's better to proceed with the new file hierarchy to avoid painful rebasing.

[yannham]

Ah, so the path is nickel-lang-cli, but the crate name will be nickel-lang ? Hmm...that sounds a bit confusing. On the other hand, I agree that nickel-lang is a bit misleading.

[vkleen]

At some point, I had the CLI just under cli, like the utilities subdirectory now. I don't think there's any paritcular necessity to tie the directory name to the crate name, and just nickel-lang felt a bit misleading as you say.

[vkleen]

I'm still not 100% sure about the nickel-lang vs nickel-lang-cli sweat_smile but I guess if we want to change that for the next release, it's just a small search and replace, isn't it? It's better to proceed with the new file hierarchy to avoid painful rebasing.

It's not quite a search and replace, but we're not using the string "nickel-lang" in all too many places, so it's not very painful. I agree that it's better to proceed as is and switch the names around later if we feel like it.