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

pythonPackages.pkgconfig: use same setupHook as pkgconfig #55722

Closed
wants to merge 1 commit into from

Conversation

catern
Copy link
Contributor

@catern catern commented Feb 13, 2019

This setupHook is necessary for actually using pkgconfig. Without this
setupHook, you need to put both pythonPackages.pkgconfig and pkgconfig
into your buildInputs, just to get the setuphook of the latter.

Previously, pythonPackages.pkgconfig depended on pkgconfig as a
propagatedBuildInput, so this setupHook was propagated down to
dependents. That was changed to a regular nativeBuildInput, so now
this setupHook change is necessary for packages to only depend on
pythonPackages.pkgconfig.

A possible alternative is extracting out a common pkgconfigHook
package and having both pythonPackages.pkgconfig and pkgconfig depend
on that with propagatedBuildInputs. That might be necessary to avoid
the buildHook running twice?

Motivation for this change
Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • 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/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

This setupHook is necessary for actually using pkgconfig. Without this
setupHook, you need to put both pythonPackages.pkgconfig and pkgconfig
into your buildInputs, just to get the setuphook of the latter.

Previously, pythonPackages.pkgconfig depended on pkgconfig as a
propagatedBuildInput, so this setupHook was propagated down to
dependents. That was changed to a regular nativeBuildInput, so now
this setupHook change is necessary for packages to only depend on
pythonPackages.pkgconfig.

A possible alternative is extracting out a common pkgconfigHook
package and having both pythonPackages.pkgconfig and pkgconfig depend
on that with propagatedBuildInputs. That might be necessary to avoid
the buildHook running twice?
@vcunat
Copy link
Member

vcunat commented Feb 13, 2019

I think we had some discussion about this around this point: #54306 (comment) I'm not a python person, so I try not to interfere too much.

@catern
Copy link
Contributor Author

catern commented Feb 13, 2019

That discussion is about not putting pkgs.pkg-config into propagatedBuildInputs. It's always a good idea to move things out of propagatedBuildInputs when it can be done. But the oversight in that discussion is that any usage of pythonPackages.pkgconfig essentially requires the build hook from pkgs.pkg-config be present. At the moment that means you have to always depend on both, but I think it's better for pythonPackages.pkgconfig to set the build hook itself.

@FRidh
Copy link
Member

FRidh commented Feb 14, 2019

I did not think about the setupHook when I patched pythonPackages.pkgconfig and removed pkgconfig from propagatedBuildInputs. Don't know what the best solution is here. I suppose this is fine.

Copy link
Member

@FRidh FRidh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

target staging

@vcunat
Copy link
Member

vcunat commented Feb 15, 2019

Oh, right, I didn't immediately realize what exactly is done by this setup hook.

@FRidh
Copy link
Member

FRidh commented Feb 15, 2019

I've included this change in #55757.

@vcunat
Copy link
Member

vcunat commented Feb 24, 2019

In staging-next ATM.

@vcunat vcunat closed this Feb 24, 2019
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