If we add the unwrapped packages to the final environment, won't that just create collisions between the binaries and their wrappers? I don't think we want to do this.

I thought so too and initially wanted to set higher priority for the wrapper to remedy this. However, experiment showed that somehow that's not the case:

$ nix-build -E 'with import ./. {}; buildEnv { name = "foo"; paths = [ kde5.gwenview ]; ignoreCollisions = false; checkCollisionContents = true; }'

completed without any collision warnings. I'm still wary of this however (that's part of why I'm unsure if this is a good idea). It solves problem of linking unwrapped /share on the other hand.

I think it won't collide when you evaluate buildEnv, but later, when you try to install it to an environment!

Aren't collision warnings printed by buildEnv builder script? environment.systemPackages is also buildEnv so if we don't get them with this command we shouldn't get them at all. Still, I'm not sure there isn't anything else in the equation...

The first buildEnv doesn't see a collision because it hasn't included the propagatedUserEnvPkgs yet. The final buildEnv is going to look at the propagated-user-env-pkgs file we create in this expression and then it's going to try to include all those packages; that is when the collision will occur.

That's right, but my test adds wrapped derivation as its path, so it creates the scenario that you describe and yet, somehow, collision doesn't occur. Why it isn't is beyond me. To show it in more verbosity, this Nix expression:

with import <nixpkgs> {};

let
  pkg = kde5.kdeWrapper {
    unwrapped = [ kde5.gwenview.unwrapped ];
    targets = [ "bin/gwenview" ];
    paths = [ kde5.kipi-plugins ];
  };

in buildEnv {
  name = "foo";
  paths = [ pkg ];
  ignoreCollisions = false;
  checkCollisionContents = true;
}

should be equivalent to my older experiment (so, it won't show collision warnings). I can't reproduce it right now to be sure though because my ISP blocks cache.nixos.org again -_-. Can you try?

It turns out that buildEnv automatically ignores collisions involving propagatedUserEnvPkgs, so this is all fine!

You're definitely right to remove this. What I can't decide is: do we need to instead link the /share paths from the unwrapped packages? I think probably not, for standalone applications, so don't worry about that yet.

I think we need to do this because of /share/applications and other paths that we would want to see in the user environment.

That's true. What we should probably do, then, is to switch from mkDerivation to buildEnv and set pathsToLink = [ "/share"]. We can set up the wrappers in a postBuild script. Does that sound good?

This would give us the same problem -- unwrapped packages' propagated-user-env-pkgs would get there too, and so we'll get collisions later.

That's OK! buildEnv is smart enough to avoid collisions if the same package ends up in propagatedUserEnvPkgs many times. What it is not smart enough to do is avoid collisions if you have two different packages that provide symlinks to the same destination! That's the root problem here.

If I understand correctly exactly this would happen:

1. buildEnv №1 (that is, kdeWrapper) makes /share including all packages propagated with propagatedUserEnvPkgs;
2. buildEnv №2 (environment.systemPackages) has №1 as its input (including symlinks to some propagated foo) and also foo as its second input. Here we get a clash!