Scope of crate2nix and future of rusty nix

[kolloch]

I think it makes sense to think about the goals of crate2nix and the other two projects providing nix build support to rust. Then we can maybe converge or find at least topics to collaborate on. And we can help nix/rust users choose the best solution for their projects.

This is WIP, feel free to discuss. Obviously, these are goals

Core goals and features:

1. Generates nix derivations for rust binaries and libraries that have crate cache granularity.
2. Convenient to use.
3. Stable interface. Both the CLI and the generated build files should not have random interface changes. Support the old interface in new versions, at least for a while, if offering new interfaces.
4. Stable implementation. Strong regression tests so that new releases don't break what already worked.
5. Works in fully sandboxed mode.
6. Convenient "import-from-derivation" support which allows not to check in the generated "Cargo.nix" file. See Document "import-from-derivation" mode (tools.nix) #110, Support for git sub modules in vendoring in tools.nix #101
7. Support for selecting features at eval time (and not only at generation time).
8. Good support of nixpkgs target platforms Linux and Mac OS.

Developer convenience:

1. Good testing support (cargo test).
2. Good nix-shell support. See nix-shell support #111
3. Support for git sources with sub modules.
4. Support bigger workspaces and collaboration. That deserves examples:
   • crate2nix currently stores hashes of prefetched sources in crate-hashes.json. If this is checked in, this can lead to merge conflicts. Therefore, I propose a change that prevents this: Prevent merge conflicts with crate-hashes directory #82
   • If crate2nix or evaluating the generated build file takes too long, that's worth some optimizations even if that increases code complexity.
5. Fast debug builds.

Packaging features:

1. Convenient support for out-of-tree builds ala nixpkgs where the root crate/worksapce is fetched. See Convenient support for out-of-tree sources #102
2. Works out-of-the box for all common open source crates if they are not too crazy (e.g. make building in a sandbox deliberately difficult). This can be achieved by making buildRustCrate and crate2nix better or by getting appropriate pull requests merged.
3. Make the output reasonably small.

Cross building (currently no support at all):

1. WASM build support.
2. Cross builds e.g. for Windows. Might be difficult, I don't know.

Out of scope:

1. Convenient, non-sandboxed builds.