Generate options.json locally

[xaverdh]

I think the options.json list should be generated locally instead of downloaded from channels.nixos.org. That will make it consistent with other operations which take nixpkgs to be the local version from NIX_PATH.

I wrote a quick dirty demonstration of this approach here.

[pmiddend]

Thanks @xaverdh for providing this alternative. I'd have loved to just generate options.json, but simply didn't know how to. I'll try your solution soon.

[pmiddend]

Okay, not only did I try your solution, I actually just merged it into master. I appended another commit to it, basing the process stuff on NixManager.Process, and I also removed the now unneeded dependencies on, for instance, wreq. Thanks for the work you did, really glad to have a more robust solution than downloading this JSON file in nixos-manager! :)

[xaverdh]

Cool!
Actually calling it "Download" is probably no longer accurate now. But maybe we don't want the user having to click a button anyway?
I think a good approach might be to keep a second file along with the options.json link, containing a nixpkgs hash
(e.g. generated from nix-instantiate --eval -E 'with import <nixpkgs> {}; lib.version' ). On startup we could compare a newly generated hash with the old one, to detect if the systems nixpkgs version changed. In that case we can write the new hash and regenerate the options.json file.

On a side note: What should happen in case of breaking changes to the service definitions? The written services.nix might become invalid then.

[pmiddend]

You're right in that "Download" is misleading now. I haven't changed the wording yet, so I'm putting this on my near-future todo.
What I'd like to prevent is a slow startup of the application. (Startup might already be slow, because we're calling nix search on startup - I haven't benchmarked this yet.)
I also haven't benchmarked the options.json generation yet. If it's "fairly fast", I'm all for not annoying the user with an explicit generation step.
I also really like your concept of the version number and the auto-refresh. If everything is fast enough, we should do stuff automatically.
Regarding breaking changes...good question? :D

[xaverdh]

Opened #5 for tracking the breaking changes question.