NixOS module compatibility

[jrobsonchase]

Complete compatibility obviously isn't possible, but for things like auto-generated cachix configurations, it would be convenient to reuse them in nix-on-droid.

Continuing with the cachix config example, NixOS has nix.binaryCaches and nix.binaryCachePublicKeys, while nix-on-droid has the equivalent nix.substituters and nix.trustedPublicKeys. Instances such as these where attrs have the same type and semantics should favor the NixOS names rather than create new incompatible ones that break compatibility.

[Gerschtli]

We do not break compatibility because we never wanted that between NixOS and nix-on-droid. WIth your examples: We aligned to the new wording of latest nix releases, NixOS just still uses the deprecated namings. So we will not rename option to a deprecated wording. Ideally these options should be renamed in NixOS.

Like you said, there will never be compatibility between NixOS and nix-on-droid but if you would like to see new options added to nix-on-droid, feel free to open an issue or a PR.

[jrobsonchase]

We aligned to the new wording of latest nix releases, NixOS just still uses the deprecated namings. So we will not rename option to a deprecated wording. Ideally these options should be renamed in NixOS.

While I agree in principle, from a practical perspective, getting that changed in NixOS is much more difficult than adding compatibility here. Big, slow-moving projects, etc. etc.

I've used the mkRenamedOption pattern in home-manager modules to add new names for options while keeping deprecated support for the old name around. Would it not be possible to retcon the NixOS options as the "old" name in cases like these?

[Gerschtli]

I do not get why this would be that difficult in NixOS? Just plug in a mkRenamedOption. I can create the PR (if not already one present) in a few days.

In the mean time you can add the mkRenamedOption in your own config if you need these aliases but I do not see the big benefit because you will never be able to share your whole config between NixOS and nix-on-droid and if we start with these two options then we should be somehow consistent with this compatibility approach which does not look reasonable to me.

[jrobsonchase]

And will such a change in NixOS make it back to the stable release channels as well? I'm not super familiar with where option renames are allowed to land stability-wise. If it's just the -unstable branches and the next stable release, then the upstream rename is a non-starter as far as this issue is concerned. It means that anyone wanting to share configs that should be compatible won't be unable to until the next release (and they actually migrate to it), unless they're using unstable. Even then, it still forces migration from the user.

you will never be able to share your whole config between NixOS and nix-on-droid

You're moving the goalposts - I never suggested that the whole config should be sharable. There's obviously been some effort to keep things semi-compatible since many of the attributes do line up. It doesn't seem unreasonable to keep with that effort.

[Gerschtli]

Out of interest: Do you have a concrete use case where you want to share the exact same config file for NixOS and nix-on-droid?

See https://github.com/NixOS/nixpkgs/pull/152950.

[jrobsonchase]

Yes - the example options I provided were from my attempts to use the files generated from cachix use <cache name>.

As I said before, unless the renames trickle back to the stable branches, renaming things upstream in NixOS to match nix-on-droid doesn't solve this problem. In addition, you'd also want to make the change in cachix so that it generates the proper attributes, which isn't going to happen unless they increase the minimum supported NixOS release, or put it behind a flag.

So I still stand by my earlier statement that it's much easier to accept the established options here than it is to make the rest of the world change to match.

[Gerschtli]

But doesn't cachix generate the nix.conf file? This one can just be used like that.

Just to be clear: We are not the reason that makes "the rest of the world change", this change of terminology originated from a recent nix release. Therefore, it is not "renaming things upstream in NixOS to match nix-on-droid" but "renaming things upstream in NixOS to match nix".

[jrobsonchase]

No, on NixOS, it generates a NixOS module since nix.conf is an immutable file in the store. The configuration for each cache looks like this:

{
  nix = {
    binaryCaches = [
      "https://nix-on-droid.cachix.org"
    ];
    binaryCachePublicKeys = [
      "nix-on-droid.cachix.org-1:56snoMJTXmDRC1Ei24CmKoUqvHJ9XCp+nidK7qkMQrU="
    ];
  };
}

Just to be clear: We are not the reason that makes "the rest of the world change", this change of terminology originated from a recent nix release. Therefore, it is not "renaming things upstream in NixOS to match nix-on-droid" but "renaming things upstream in NixOS to match nix".

Sure, but it doesn't really matter what motivated the change. It's still a slow process to get everything updated since some people would likely need to wait until the new names are backported to the stable branch that they use (if that ever happens) before they can actually use them. In the meantime, it's impossible (or at least inconvenient) for them to share configs using them between NixOS and nix-on-droid.

"Be liberal in what you accept"

[Gerschtli]

FYI: NixOS did a bit of refactoring here. https://github.com/NixOS/nixpkgs/pull/139075