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: ).