sternenseemann

> Dito. What are you replying to, exactly? As for this thread, the relevant detail from my infinitely long discourse post is that I still plan on fixing this problem...

There is some nuance to it, since there is a difference between being given a cabal file and being given source code. This difference is already present in the fetcher...

Indeed, it is hard (to impossible) to fix if we still want to leverage splicing to facilitate correct cross compilation as it works today. Are you running into it for...

> but seems in name of perfection, nothing is done instead I want to repeat my question: Where are you running into this, specifically? I'm a bit surprised by your...

I think documenting `shellFor` at the very least is in order which I've started [here](https://github.com/NixOS/nixpkgs/pull/126674/commits/31d721a38bcefd093d212070b2b004a2faa842ad). Some automation improvements could be nice, but I'm not certain how that could look. With...

I think support for cabal.project files can probably be implemented as a feature for shellFor in nixpkgs given someone looks into implementing the required globbing (which can probably be adapted...

I think support for cabal.project files can probably be implemented as a feature for shellFor given someone looks into implementing the required globbing (which can probably be adapted from gitignore...

I think it's just easier to generate a single file and more obvious. As you can see from the top 10 of files with the most lines in nixpkgs, we...

> Would having 16000 files in a directory cause any problems? Yeah, that is the big question.

> Have you actually tested whether this is true? I believe that Nix parses included files even if they are not actually needed for the evaluation. I may be wrong...