[Nix-dev] getPkgConfig considered harmful

[Andres Loeh]

If I understand getPkgConfig correctly, then

  getPkgConfig A B default

will check the configuration file for a key A.B, and if that is not
present, for a key B. As a final resort, if neither A.B nor B are set,
default is returned. A common use case is to say

  if getPkgConfig "mypackage" "myfeature" false then ... else ...

in order to conditionally enable something depending on a user-defined
flag. If myfeature is shared between multiple packages, then a user
can globally specify whether (s)he wants the feature by saying
"myfeature = ..." in the config file.

The problem arises once there is another line somewhere in Nixpkgs that says

  getPkgConfig "myfeature" "foo" false

in other words, if "myfeature" happens to be the name of another package.

This problem is real. One example where this problem currently arises
is the following: In all-packages.nix, in the definition of distcc, we
have

  python = if getPkgConfig "distcc" "python" true then python else null;

There are several other lines of the form

  getConfig ["python" ...]

That means, if someone sets for instance python.curses = true in the
configuration file, then the getPkgConfig line above will result in a
run-time type error.

I think this problem needs to be addressed. I know that Eelco dislikes
getPkgConfig/getConfig in general, and I tend to agree. However, I do
not want to propose any far-reaching changes. A relatively easy fix
would be to make getPkgConfig A B not check A.B and B, but A.B and
global.B (or some other name instead of global). That would
significantly reduce the chances of name clashes.

Cheers,
  Andres