Stabilize nix copy

[bjornfor]

Describe the bug

Starting with Nix 2.x, nix-push got removed and replaced with nix copy. But later, nix copy was marked as an experimental command, meaning there is no longer a stable CLI to copy paths around?

Expected behavior

When removing a stable command, there is a migration path to a new stable command. (Preferably with some overlap in time.)

Priorities

Add 👍 to issues you find important.

[bjornfor]

Related: #7701

[fricklerhandwerk]

Discussed in the Nix team meeting 2023-03-17:

We'll try to stabilize nix copy (with a very small subset of installable and flags so that we don't commit too much).

This is now part of #7701 (comment)

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-03-17-nix-team-meeting-minutes-41/26614/1

[fricklerhandwerk]

Discussed in Nix team meeting 2023-03-20:

We still agree we'll want to make that functionality stable. But we had a long discussion on the general design approach, without conclusion for now.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-03-20-nix-team-meeting-minutes-42/26615/1

[thufschmitt]

Discussed during the Nix maintainers meeting on 2024-01-30.
The only blocker for stabilization (modulo the whole installables things and other global concerns) is to get rid of --no-check-sigs and make sure that ?require-sigs=false on the destination store does the right thing.

Last discussion was about a split between a full-blown nix copy and a store-only nix store copy-path. Resolved since we aggreed that the store-only/full-blown distinction would mostly be about which installables are allowed.

• --no-check-sigs: Confusing: There's several ways of specifying that, some working, some not. Need to fix it.

  • Ideally should just be a store option (to set on the destination)

• @tomberek: Too easy to accidentally copy things without the signature / with different signatures.

  • Using ?signing-key= can alleviate that a bit (just documentation issue)
  • It could be good to have the store itself check that the things are signed
  • Orthogonal to the CLI

• --substitute-on-destination

  • Disabled is annoying because we shouldn't care what things are gotten; it's great to download from multiple places to e.g. get more bandwidth
  • Enabled is also annoying because thanks to input addressing, different stores will not necessary provide the same store object!

• Warning if all 3 of --from / --to / --store might be nice. (Idea is that specifying --store but other flags cause it to be ignored is a gotcha.) This is not blocker.

Summing-it up:

• Blockers for stabilization:
  • Get rid of --no-check-sigs and make sure that ?require-sigs=false on the destination store does the right thing
    • N.B. This will mean removing the checkSigs parameter from copyPaths, and maybe a couple other knock-on (like Domino) tasks.
• Nice to have
  • Document ?signing-key more prominently
  • Warn when --from --to --store is used (all three at the same time)

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2024-01-30-nix-team-meeting-minutes-119/39185/1