I think it's fine to add the getHaskellBuildInputs function into lib.nix. I am not a fan of the notion that the generic builder uses it internally, though. The current code is not particularly beautiful, but it's a linear sequence of simple steps that are all listed in order in one file. I am reluctant to move intelligence out into a separate module unless there's a tangible benefit in terms of code simplification. I don't see that benefit at the moment. Therefore, I'd like to wait a little and see how this new feature develops (i.e. observe whether people actually use it) before committing the generic builder to that structure.

@peti I'm very frustrated about this. Isn't this exactly what you suggested in #23023 , which you used as justification to revert 3001b82 and feffade ?

I would like to have a generic way to access the haskell build inputs of a given haskell package in the exact same way as we build the nix-shell env, without a hack like (builtins.head p.env.nativeBuildInputs), which I have been using since March when you reverted my commits. Please, tell me how you would like me to do that.

To be clear, I have been using this functionality for months to build nix-buffer environments, and finally gave up and implemented #23023 when I found another use case in building hoogle-ready environments. This specific PR is unlikely to be used much within nixpkgs itself, but the feature it enables has been tested actively by production haskell development teams.

I am perfectly happy with adding that function to lib.nix. That's no problem at all! I just don't want the generic builder to use it internally. As far as I can tell, you don't need the generic builder to be based on that code? Am I missing something?

Then I have to duplicate all of the logic in generic.nix, and keep them up to date. I would strongly prefer my original approach of just re-exporting this information in passthru, or the approach of this PR to share the logic. I expect doing otherwise to cause eventual divergence, hopefully that will be caught quickly by me but most likely will be caught by a developer who is not a nix expert and will, at best, expend several of their (and, eventually, my) hours and some of their goodwill toward nix-based development environments to fix the issue. I do not understand why neither of the solutions I proposed that would keep things in sync is acceptable.

That being said, if you insist I'll push a version of this without the changes to generic-builder.nix.

Then I have to duplicate all of the logic in generic.nix, and keep them up to date.

Yes, that is true. However, I find that preferable over exposing internals of the generic builder in a public API that other people then want to rely on. Once we do that, we can no longer change internals of our build function without breaking 3rd party code that may not even be a part of Nixpkgs.

We can namespace most of this to be internal and just expose the bits we're comfortable keeping stable. There's a similar concern about stable APIs even if the absence of code sharing...

Pushed without changes to the generic builder.

Addressed all comments but the one.

Woah I really don't like the duplication. @peti I agree we're grossly spilling the guts here, but now I have to crawl through 3 sources of truth (generic-builder, lib, and generic-builder env) to fix all the deps for cross. This is going to really be a pain, and I'll take the grossness not the pain.

@Ericson2314, I totally see your point. The question is just, what do you suggest we do? Exposing all those internals is no good solution either.

Personally, I view these new functions as experimental and I would not go out of my way updating them when I make changes to the generic builder because I don't even khow to test that code.

@peti If its experimental, then we can break it at any point. It's just another implementation that happens to be in the "wrong file". I wouldn't be too surprised if @shlevy was OK with a situation where perhaps you just ensured that nixpkgs at least evals whenever you change it, and he's on the hook for making sure whatever uses he introduces still work semantically. That's not great, but arguably better than what we have now. Longer term, we have some nixpkgs test.* derivations now and could whip up a small example/test there.

Longer term still, I hope to finally have time to teach cabal new-build some new tricks now that cross compilation is wrapping up, so perhaps the "develop multiple packages at once" functionality wouldn't need this.