Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

buildEnv: respect user-chosen output even with extraOutputsToInstall #15816

Closed
wants to merge 1 commit into from

Conversation

abbradar
Copy link
Member

Motivation for this change

When user gives an explicit output for buildEnv, for example gcc.cc.lib, if extraOutputsToInstall is specified gcc.cc.lib.foo would also be included, even though this might not be what the user wanted. This reverses the behaviour, so if an output is explicitly specified no additional ones would be installed.

For example of when this is useful: this removes gcc.out references from buildFHSEnv environments.

Not mass-rebuildy as far as I can see.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • OS X
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

By analyzing the blame information on this pull request, we identified @vcunat, @edolstra and @aszlig to be potential reviewers

@abbradar
Copy link
Member Author

cc @vcunat -- was there a purpose for the initial design?

@vcunat
Copy link
Member

vcunat commented May 30, 2016

Well, this depends on what the option is supposed to mean, as the user explicitly passed extraOutputsToInstall, too. I can't see a clear winner ATM.

Note that this is set by nixos config for the system env, and this PR may e.g. exclude some man pages in some configs (when modules put foo.out or foo.bin into systemPackages). It would seem better to me to include them in those cases, but maybe that should be expressed in some other way...

@abbradar
Copy link
Member Author

Hmm, indeed. Maybe this should be rather documented with some workaround... maybe toString would help. I'll test later.

@vcunat
Copy link
Member

vcunat commented May 30, 2016

removeAttrs gcc.cc.lib ["foo"] should certainly work in your case, but it utilizes knowledge about buildEnv implementation...

@abbradar
Copy link
Member Author

abbradar commented May 31, 2016

After more thinking, it does seem to me that not respecting extraOutputsToInstall when an output is chosen is more logical, because one can guess that without knowing our "outputs are recursively available in outputs" thing. That is, one might more likely expect that when he specifies foo.lib, foo.bin won't be used because it's not exposed at all.

However, I feel too biased to make any conclusions, and also completely skip the question of convenience (current way may make some patterns easier) and cost of changing vs benefits (it seems we don't use that corner case much, but I cannot testify). So I'm unsure how to proceed with this...

EDIT: ...and this might very fast roll down to a bikeshedding festival.

@abbradar
Copy link
Member Author

abbradar commented Jun 5, 2016

Let's just document this behavior for now, I think.

@7c6f434c
Copy link
Member

@abbradar so are you going to document this? Should this be merged? closed? I guess you can merge it youself…

@abbradar
Copy link
Member Author

I forgot about this completely D:

As I've said this is a controversial change without much benefit -- I'm personally for it but unless there is strong support I say let's just close it. I'll write documentation (and try not to forget this time :D) if workarounds listed in it would seem too awful we might return to this question ~_^

@abbradar abbradar closed this Mar 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants