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

WIP: wrapAppsHook: unify wrapper generation Gapps/Python/Qt/... #102949

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

FRidh
Copy link
Member

@FRidh FRidh commented Nov 5, 2020

Motivation for this change

We have several hooks that generate wrappers. When multiple of these are used in a build, this results in nested wrappers. Typically, we disable the wrapper generation of all but one of the hooks then, but this is a manual step.

With this change, a new hook is created that is propagated by the other hooks (GApps/Python/Qt). These hooks export to an environment variable of their own, but also to a common variable which the new hook will then use.

This is a prerequisite to go to declarative wrappers as well.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • 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 nixpkgs-review --run "nixpkgs-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)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

TODO

This is not functioning yet.

Long ago we used pth files for finding Python dependencies. Around the
time we changed to the wheel builder that feature was no longer used.
wrapPythonProgramsIn both wraps and patches.

Long-term, we should separate this further.
This is where all Python-related hooks can be found.
instead of requiring the user to always invoke `wrapPythonPrograms`
manually.
… variable

In Nixpkgs we have multiple hooks that generate wrappers using
`makeWrapper`. This more than occasionally results in nested wrappers,
because multiple hooks invoked `makeWrapper`.

This commit introduces a new hook, `wrapAppsHook`, that solves the
nested wrapper issue and deduplicates some logic. This hook invokes
`makeWrapper` to build wrappers and loads its arguments from
`appsWrapperArgs`. Other hooks that create wrappers should export to
this environment variable and propagate this hook.
First need to switch from propagatedBuildInputs to requiredPythonModules.
@FRidh FRidh added this to the 21.03 milestone Nov 5, 2020
@@ -0,0 +1,79 @@
# shellcheck shell=bash
appsWrapperArgs=()
Copy link
Member Author

Choose a reason for hiding this comment

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

Do we want to use this variable, or something else? Originally I had makeWrapperArgs, but that will conflict with the current (rare) usage of makeWrapperArgs of Python packages.

# TODO: further checks
# Following is done e.g. for Qt
#
# patchelf --print-interpreter "$file" >/dev/null 2>&1 || continue
Copy link
Member Author

Choose a reason for hiding this comment

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

This is the Qt check I mentioned. In my opinion we should wrap scripts as well. If there are scripts or simply executables to exclude, we should consider supporting an include and exclude list.

Copy link
Member

Choose a reason for hiding this comment

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

Yup, we should wrap those too – we had issues where PyQt programs were not properly wrapped.

@@ -0,0 +1,11 @@
# # Patch Python executables
Copy link
Member Author

Choose a reason for hiding this comment

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

wrapPython does both patching and wrapping. Ideally that is split into two.

# We need to support both the case when makeWrapperArgs
# is an array and a IFS-separated string.
# TODO: remove the string branch when __structuredAttrs are used.
if [[ "${makeWrapperArgs+defined}" == "defined" && "$(declare -p makeWrapperArgs)" =~ ^'declare -a makeWrapperArgs=' ]]; then
Copy link
Member Author

Choose a reason for hiding this comment

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

makeWrapperArgs would disappear, because we will have the appsWrapperArgs.

There is some code here for backwards-compatibiltiy as well that will be removed.

[ -z "$wrapAppsHookHasRun" ] || return 0
wrapAppsHookHasRun=1

local targetDirs =( "$prefix/bin" "$prefix/sbin" "$prefix/libexec" )
Copy link
Member Author

Choose a reason for hiding this comment

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

Each of the hooks had a different set of targetDirs. I chose to consider all of them.

@@ -122,6 +122,12 @@ in rec {
};
} ./python-remove-tests-dir-hook.sh) {};

pythonWrapExecutablesHook = callPackage ({ wrapPython }:
Copy link
Member Author

Choose a reason for hiding this comment

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

This hook would replace wrapPython, so users typically do not need to invoke wrapPythonPrograms(In) anymore. cc @jonringer

done
done
# Extend the appsWrapperArgs for wrapAppsHook
appsWrapperArgs+=qtWrapperArgs
Copy link
Member

Choose a reason for hiding this comment

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

I'm sure you know Bash better than I do 😅 but why isn't this,

appsWrapperArgs+=( "${qtWrapperArgs[@]}" )

@stale
Copy link

stale bot commented Jun 3, 2021

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jun 3, 2021
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/low-effort-and-high-impact-tasks/21095/41

@Artturin Artturin modified the milestones: 21.05, 23.05 Dec 31, 2022
@stale stale bot removed 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md labels Dec 31, 2022
@RaitoBezarius RaitoBezarius modified the milestones: 23.05, 23.11 May 31, 2023
@rnhmjoj
Copy link
Contributor

rnhmjoj commented Jun 12, 2023

So, it's 2023, it's been 6 years since #25351, we're still shipping broken packages but we now have structured attributes (opt-in via __structuredAttrs = true) in stdenv. What's the next step?

If this is not going to be done for the couple of release, I would ask you to reconsider merging #83321, which works well and is a significantly simpler solution. I understand the appeal of a grand unified wrapping scheme to solve all this issues, but if it's going to take ten years, I rather implement the stop gap solution now: it's not going to make the matter any worse.

@wegank wegank added 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 2.status: merge conflict This PR has merge conflicts with the target branch labels Mar 19, 2024
@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Mar 20, 2024
@rnhmjoj
Copy link
Contributor

rnhmjoj commented Apr 21, 2024

ping

@wegank wegank added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.status: merge conflict This PR has merge conflicts with the target branch 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md 6.topic: python 6.topic: qt/kde
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants