I though we were moving towards foo.pkgs as it makes it harder to have a mismatch of foo versions.

I don't follow you here. Do you refer to how we pass in say python or pythonPackages instead of the individual Python packages to a non-Python package? That is indeed to prevent mismatches, however, it does not matter whether it is python or pythonPackages.

I meant that if we have two top-level attributes, overriding just one in an overlay can cause mismatches (unless they refer to each other through scoped names but that has its own downsides). Stuffing everything under the interpreter allows us greater control over references thanks to encapsulation (but maybe at performance cost compared to just bare scopes?).

I thought we do: fooPackages = lib.recurseIntoAttrs foo.pkgs;.

recurseIntoAttrs only has effect on whether tools will try to find packages under that attribute. How coupled the two attributes are depends on which scope does foo come from.

I've always been wary of foo.pkgs because one compiler/interpreter can build multiple package sets. Having the package set of a tool is philosophically backwards, it should be the compiler/interpreter of the package set.

it should be the compiler/interpreter of the package set

In theory, I would agree. In practice however this makes it so that you have to take care to not pass an incompatible Python version along with it's set.
I think the practicality of this outweighs any philosophical notion.

But in practice both python3.pkgs and python2.pkgs would be the same sets, but with different behavior depending on the python versions which dynamically determine the value of disabled and similar stuff. In that sense it isn't even possible to pass an incompatible python interpreter if I'm not mistaken.

Also in other language-specific package sets there is much less breakage between compiler versions than between python2 and python3 where it would make even less sense.

For PHP, we create the php.pkgs internally in the PHP derivation “template” function. That is, a package set for the new variant is just created automatically when the variant is created (e.g. using import "${nixpkgs}/pkgs/development/interpreters/php/generic.nix") { version = "..."; sha256 = "..."; }.

From the looks of it is somewhat similar to the passthru for Python.

Do we even want nesting? For example, for PHP, we could have two clearly separated package sets:

• tools – those are just scripts written in PHP, they would probably not even need to be under PHP, just like we do not put Python applications to python.pkgs.
• extensions – shared libraries linked against PHP that PHP needs to load at startup

PHP does not really need something like python.withPackages since PHP packages are just text and it is the application, not PHP runtime, responsible for loading them. (AFAIK unlike in Python, anything binary needs to be an extension, not a regular autoloaded package.)

Do we even want nesting?

I don't know actually. So far it seems we have not, so we can just leave it out of the RFC.

For PHP, withPackages does not make sense either, since we do not actually package any packages other than applications.

For the extensions, I think that it should be php.withExtensions since that does not create an environment but creates a config file listing the extensions and wraps php with a path to the config file.

I think this shows why withPackages is often enough, but not always and it hence should be a recommendation, but not a rule. In the end, we need a more powerful buildEnv that can compose an environment given a mixture of types of packages using certain rules.

"powerful buildEnv" -> #75 ...

Somewhat related NixOS/nixpkgs#75485

Referring to the incorrect set NixOS/nixpkgs#114538