buildFHSEnv overriding

Development Nixpkgs Architecture
1

I noticed that there currently seems to be no way to override inputs to buildFHSEnv as it isn’t wrapped with lib.makeOverrideable and overrideAttrs is also not functional to pass a modified targetPkgs for example.

Is there a architectural reason overriding was not considered or was it just forgotten?

5 Likes
2

No and it’s in dire need of a refactor anyways. Feel free to hack on it if you’re motivated.

As long as the external API for callers of the builder remains in-tact (or has reasonable changes) I don’t think anyone would disapprove.

1 Like
3

for now i wrapped it in lib.makeOverridable, but as pointed out it should be refactored. When are the bulidFHSuserEnv aliases supposed to get deprecated btw? I think it should be safe to add a deprecation warning as they are no longer used in nixpkgs.

1 Like
4

Deprecations should last until at least the next release, after which it could be removed.

5

Can you please elaborate?

6

I’m not sure what’s you want me to elaborate on here; someone needs to have a good look at the code and organise it better.

8

Whats the state of this PR? seems to be in limbo right now.

9

I need to rebase it (again) due to other PR’s having created a merge conflict. Apart from that the interest in it seems to be low.

10

I know I have a need for it. The package for envision (a tool for managing builds of monado and Opencomposite) uses a buildFHSEnv wrapper and dependencies are often added to those projects that need adding to the environment envision works in. Being able to override buildFHSEnv packages can alleviate some pain points when a new dependency gets added to those projects that hasn’t been addressed in the envision package yet.

1 Like
11

I just rebased onto master. From my point of view the pr is ready as it improves the status quo (objections are also welcome in the PR :wink: ).

12

Just wondering what’s happening with this PR since this discussion seems to have died out and the PR has similarly had nothing happen with it from what i can tell

13

It’s ready from my point of view, just waiting for someone interested to review it.

3 Likes
14

Is it possible to do the overriding with overrideAttrs instead?

We have been working hard to unify the overrider, and overrideAttrs (added with stdenv.mkDerivation) is much feature-complete than override (added with lib.makeOverridable).

In addition, a derivation constructed with buildFHSEnv is often a package to be called with callPackage and provided under pkgs. callPackage will add a override attribute to the package (known as the <pkg>.override interface), shadowing any previously-defined override attribute.

1 Like