search

maralorn / nix-output-monitor

Pipe your nix-build output through the nix-output-monitor a.k.a nom to get additional information while building.
GNU Affero General Public License v3.0
942 stars 29 forks source link

Parse options to get the store path if it has been modified #158

Open myclevorname opened 3 weeks ago

myclevorname commented 3 weeks ago

A partial solution I would propose to the limitation of the store path assumption is to parse the options provided to Nix to see if the user provided --store, and falling back to /. Then, append /nix/store to the end to get the store path. This wouldn't work if the store path was modified in nix.conf.

maralorn commented 3 weeks ago

I vaguely hope to get away from directly reading the nix store anyway and only interfacing with it via nix. That would probably help in most cases.

But I wouldn’t be strictly opposed to doing something like this. It wouldn’t make anything worse.

lheckemann commented 6 days ago

If you do this, the NIX_REMOTE environment variable should also be taken into account :)

maralorn commented 6 days ago

I am not certain yet, but I am kinda hoping that we can get away with never looking into the nix-store ourselves and instead just query nix for data. That way environment and config will be dealt with correctly. Only thing we need to figure out is which flags need to be forwarded to internal nix calls.

Until we solve that, are NIX_REMOTE and --store the only two options which we need to consider?

lheckemann commented 5 days ago

You can also set store in nix.conf, which in turn is picked up from multiple locations 🫣 I absolutely agree that only going through nix would be ideal, though I suspect we'd still have to work out what the store is?

eval-store might also be relevant -- I think the drvs end up in both eval-store and store but would usually make more sense to read from eval-store...