cc @Profpatsch @vcunat

I'm not sure what you mean by "split packages". I guess some practical examples would help.

I think it's been very rare in nixpkgs not to have $out. One reason is that it's where typical $PREFIX goes (many tools have some notion like that).

I'm not sure about your use cases, but why REMOVE as the added fallback? Off the top of my head, I'd expect the first output to be a better choice, which could be done (I think) simply by $outputs instead of REMOVE. Or on the whole... perhaps it would be best to start by choosing some of the outputs as default and assign it to $out? Some hooks just need some kind of overall default output (say $PREFIX).

I'm not sure what you mean by "split packages". I guess some practical examples would help.

"split packages" is a derivation contains many commands, such as those in unixtools.
I'm rewriting adv_cmds and it provides many commands including ps, which is required by cmake in bootstrap stage, so it should be better split without building other unnecessary. (That's what we are doing in adv_cmds/boot.nix now.)

I think it's been very rare in nixpkgs not to have $out. One reason is that it's where typical $PREFIX goes (many tools have some notion like that).

I'm not sure about your use cases, but why REMOVE as the added fallback? Off the top of my head, I'd expect the first output to be a better choice, which could be done (I think) simply by $outputs instead of REMOVE. Or on the whole... perhaps it would be best to start by choosing some of the outputs as default and assign it to $out? Some hooks just need some kind of overall default output (say $PREFIX).

They're rare and mostly standalone commands without libs, so typical $PREFIX and the multiple-outputs.sh fixup are in fact meaningless in such cases. There is a trick to solve it by keeping out in outputs and touch $out at the end (dozens of search results in nixpkgs). I'm thinking why not getting rid of that trick since $out should not be necessary (make #16182 possible).

The REMOVE-fallback solution isn't nice I admit, so it's made drafted. I hope we could find a better way to disable all those directory mangling hooks.

I’d like this change, since it removes a slight annoyance, but I can’t really help with implementing it.

Problem is that it might break some things, and it’s hard to predict what will break if we change this now.

Does REMOVE mean silently remove? That sounds bad. I rather have it error.

Nothing in the current or planned PR should change cases where $out is used (the majority).

AFAIK REMOVE only works for the moveToOutput function – but yes, it's meant to change that move into a remove. The usual ${!outputFoo} will fail (I think we have that set for undefined variables in stdenv now), so standard configure phases would fail with it, I expect.

Close this since I'm not plan to go further. Hope some one could fix it in the future.