Most recently #19225 and #17607.

As an example, let's say I'm running a python project that requires dbm, and it produces an executable script as part of its build process. If I refer to it by ${pythonPackages.mypackage}bin/myscript, I get an error that dbm isn't available (no mention of pythonFull in the error). After that, it's not at all obvious to me how to replace the python that gets hardcoded into the shebang with pythonFull, and this is after I poke around the nix files for a while. Also, due to the wrapper script, it's not easy at all to explicitly run the script by running pythonFull against which myscript, because it's not a python script.

In the end I ended up biting the bullet and making myself a pythonFullPackages (by copying and pasting what we do for the other python package flavors and passing in pythonFull) and then using buildPythonPackage from there to build the package with myscript in it.

Ultimately though, I wouldn't expect any newcomer to Nix to have any clue what to here, or even how they'd figure out why dbm, which is generally shipped with python, doesn't import in the first place.

Where I'm going with this is that I think it'd pay to either re-evaluate having any distinction between python and pythonFull, or if that's still warranted (presumably by a huge closure size difference), to at least change the mechanism by which it happens to be less obscure.

cc @garbas @domenkozar