Remove nix-store --dump and nix-store --restore?

[bhipple]

Currently, nix has two pairs of commands for interacting with NAR files:

• nix-store --dump --> nix-store --restore
• nix-store --export --> nix-store --import

These differ in that the former can only take one path, and does not store the
requisites of a path, so it can't be imported into a nix store the way you'd
expect. It requires that all paths not already exist on the --restore end, while
the --import one can incrementally update paths and properly sync the sqlite db.

Perhaps we should delete nix-store --dump and nix-store --restore entirely,
since they appear to be less useful subsets of the export and import commands.
This would simplify the cmdline / API surface area for newcomers and reduce
ongoing maintenance.

Here's an example of a newcomer getting tripped up and using the "inferior"
dump/restore. I also spent a while staring at this at NixCon, and would like to
help remove it if indeed there's no legitimate use case for it.
#951 (comment)

[edolstra]

Well, the entire nix-store command will hopefully become deprecated in the future. The nix command has some subcommands for dealing with NARs (like nix dump-path, nix cat-nar, nix ls-nar).

But it's really the nix-store --export / --import commands that should be removed. They have a very wacky, non-extensible format that does not handle things like signatures and has other misfeatures (e.g. the metadata comes after the NAR, so on import we have to read the NAR into memory even though the store path may already be in the Nix store). So we should come up with a new format for storing closures.

[edolstra]

Closing since we don't want to break compatibility.

[AleXoundOS]

I couldn't unpack/extract NAR with nix cat-nar. Only single files from it.
But nix-store --restore works right.