nixos/networking: deprecate networking.extraHosts

[JohnRTitor]

There is already networking.hosts that replicates its features with the added benefit of defining multiple hostnames for same IP in a list.

Something like;

  networking.extraHosts = ''
    169.254.169.254 metadata.google.internal metadata
  '';

can be changed to:

  networking.hosts = {
    "169.254.169.254" = [
      "metadata.google.internal"
      "metadata"
    ];
  };

All modules in nixos/modules/** has been migrated to networking.hosts.
Usage and occurances in tests on Nixpkgs can be migrated in seperate PRs.

After a discussion on Matrix with K900, it's best we deprecate this. This option is set to be removed in 26.05. 1 year of deprecation period allows consumers to be migrated safely.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[SigmaSquadron]

I'd recommend adding an evaluation warning if the option is set, unless too many modules configure it in-tree.

[JohnRTitor]

I am seeing 54 usage in Nixpkgs, most of which come from tests.

[khaneliman]

I'd recommend adding an evaluation warning if the option is set, unless too many modules configure it in-tree.

This was my first reaction, as well.. I don't know how a user would migrate away from it until they receive notice. But, if the idea is to just add a description notice for in tree development while we wait for in tree migration, that is fine. However, a warning would also drive migration quicker :P

[JohnRTitor]

I have migrated all modules in nixos/modules/** to networking.hosts.

[philiptaron]

I like it. @alyssais, what do you think?

[PedroHLC]

I know some anime-styled games alternative-launchers that expect to see some very specific commentaries in /etc/hosts before launching/patching. How are we going to inject those comments without this field that allows abstract values?

FIY: This was attempted before #27791

EDIT: This seems more like a problem of vocabulary, misleading to bad usage patterns. Instead, this option should be renamed to something that does not mention “hosts”, like appendAbstractly, and document it to “use it as a last resource for automation”.

[JohnRTitor]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 413925

Logs: https://github.com/JohnRTitor/nixpkgs-review-gha/actions/runs/15450221622

---

x86_64-linux (sandbox = true)

✅ 5 tests built:

• nixosTests.containers-hosts
• nixosTests.kubernetes.dns-multi-node
• nixosTests.kubernetes.dns-single-node
• nixosTests.kubernetes.rbac-multi-node
• nixosTests.kubernetes.rbac-single-node

[JohnRTitor]

Note that the first commit is "general improvement". And can be merged irrespective of the decision.

[tomfitzhenry]

Nice work here, would be good to see this re-based and ready for review.

[JohnRTitor]

This kind of is "ready" for review except for the merge conflict part.

Note that treewide migration to networking.hosts had to be reverted in #415085 as it was breaking tests.

You are more than welcome to redo that PR. I am not sure on how to move forward/fix that.