Private seems kind of vague. How about writeOnly?

Done. It mirrors readOnly quite faithfully, except for not being watertight.

The usefulness of this is a bit questionable if any module can still access values via privateValue.

I've updated the PR description to match the rename. It's internalValue now, to reduce the vocabulary size.

The usefulness of this is a bit questionable if any module can still access values via privateValue.

I agree partially. Indeed any module can access the value, but no module author will use internalValue as their first choice to get their info. There module author will have to

• try config.foo
• read the error message
• not be helped or convinced by the message
• somehow learn about internalValue, digging through the module system, at which point they must already have endured significant pain from their original problem
• make the choice to ignore all warnings

If someone really ends up there, they probably really needed the value.

If it were easy, I would have written writeOnly to enforce the encapsulation, but it is not. It requires that modules are treated differently, depending on their own options. So it will require more complexity and may have the risk of being more strict, potentially causing infinite recursion problems.

Why not just use internal = true;? This way people won't even know about the option because it won't appear in the docs.

Users will need to set it. I have written this for use in config.nixpkgs.localSystem

Edit: It also applies to nixpkgs.pkgs. Module authors should use the pkgs argument instead.

If I understand correctly, you want to make uses of an option obsolete, and still be able to read its content for the time being?

Any reason not to use mkRenamedOptionModule, to produce the writeOnly error message on use, while reading the definitions from another internal option based on mkAliasDefinitions?

Adding extra attributes to evalOptionValue should be unnecessary nowadays, and would only increase the memory used by NixOS.

This feature works for options that are obsolete, as in config.nixpkgs.localSystem, but also for options usage outside the declaring module is a mistake, like nixpkgs.pkgs.

mkRenamedOptionModule doesn't seem to help much for either of these because it must remain possible for the user to set a value for these. nixpkgs.pkgs was intended to be set by the user and in case of nixpkgs.localSystem the idea was to provide backward compatibility for defining, but to disallow reading because its meaning changes when cross-compiling.

I agree that we should be careful with adding rarely used attributes everywhere in the tree. That should be a good reason to look into a different implementation that avoids internalValue, but instead injects the writeOnly values only into the declaring module. Such an implementation does not require the extra attribute everywhere and enforces the encapsulation, which may be beneficial.

The approach of just breaking config.nixpkgs.localSystem and friends may actually be a better option. Providing the backward compatibility is harder than it seems and will cause the old approach to live on as a bunch of confusing legacy options.

In conclusion, the only valid use case now seems to be config.nixpkgs.pkgs, which is not sufficient for me to write a better implementation for this. I think it is a valid use case and I would like to see a writeOnly or similar flag one day, but that day may not be soon.

@nbp Thanks for your good reviews 👍