Stick to default.nix

[SuperSandro2000]

Using pkg-fun.nix is a bad idea because generally the Fun prefix is used when constructing complex things like package sets. see https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/python/default.nix#L16 or https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel/generic.nix#L111 . Reusing it for simple package paths will create confusion and the awkward question: why was that chosen? Why not just pkg? and why it wasn't stuck to default.nix like in any other place.
It also makes the transition needlessly harder and will often raise the question why the file was renamed. Also every guide on the internet will suddenly be wrong in two ways.

Not using default.nix frees up default.nix for a short expression that is actually buildable, e.g. (import ../..).hello.

The piece of code would be almost the same for every package, hence it is better auto generated or put in the nix cli, weakening this argument quite a bit.

Also if the package should be build from the cli without the boiler plate code then the following would need to be used nix-build -E 'with import <nixpkgs> {}; callPackage pkgs/unit/hell/hello/pkg-fun.nix {}'.

For instance, having a package definition, changelog, package-specific config generator and perhaps even NixOS module in one directory makes work on the package in a broad sense easier. This is not a goal of this RFC, but a motivation to make this a future possibility.

If it isn't the goal of the RFC then it shouldn't be changed to keep the RFC smaller in size and less topics to discuss and bikesheed about.

Also having changelogs for packages is the exception and as most modules have a package option which sometimes can be replaced with multiple packages that live along side each other in tree, like nginx. There wouldn't be a definitive answer where to place the module.

For very small modules, usually under programs, they could also be placed under passthru.modules.

Right now modules are referenced by path relative to nixos/modules. Moving them would create problems and break configurations in hard to debug ways.

It would also blur the lines between nixpkgs and nixos quite a bit which wouldn't make it as clear anymore which parts are for all users and which are for nixos only.

---

TLDR: keep the default.nix filename and everything else to another RFC.

[nixos-discourse]

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

https://discourse.nixos.org/t/2022-01-23-nixpkgs-architecture-team-meeting-26/24892/1

[infinisil]

We discussed this in the last meeting. I created #32 as a follow-up.

Fun prefix is used when constructing complex things like package sets

"fun" is just shorthand for function, and it's combined with a suffix/prefix in all uses, so there won't be any ambiguity, it's also different things though. The team agreed that this wasn't a problem.

why was that chosen? Why not just pkg? and why it wasn't stuck to default.nix like in any other place.

Linking you to it again, the arguments here justify the decision, and the team still thinks that these arguments are strong enough to justify this.

The piece of code would be almost the same for every package, hence it is better auto generated or put in the nix cli, weakening this argument quite a bit.

Yes you're right, I adjusted that argument in #32, the stronger arguments are above that one.

Also if the package should be build from the cli without the boiler plate code then the following would need to be used nix-build -E 'with import <nixpkgs> {}; callPackage pkgs/unit/hell/hello/pkg-fun.nix {}'.

That is an anti-pattern that this RFC is mostly obviating the need for even. Please check out the extra section I added in #32 that talks about this

If it isn't the goal of the RFC then it shouldn't be changed to keep the RFC smaller in size and less topics to discuss and bikesheed about.

You're right on that, in #32 I moved this argument to the future work section instead.