using ^output selection syntax on store paths outputs crashes the daemon #312
Labels
No labels
Area/build-packaging
Area/evaluator
Area/flakes
Area/profiles
Area/remote-builds
Area/repl
Area/store
bug
Cross Compilation
devx
docs
Downstream Dependents
E/easy
E/hard
E/help wanted
E/reproducible
E/requires rearchitecture
imported
Needs Langver
OS/Linux
OS/macOS
performance
regression
release-blocker
RFD
stability
Status
blocked
Status
invalid
Status
postponed
Status
wontfix
testing
ux
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lix-project/lix#312
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
And in the journal we get:
which thankfully seems to point to a pretty clear place
reproduced on 2.90.0-lixpre20240512-4b35e6a. credit to julia on matrix for finding this
Reproduced on Nix 2.18. Did not reproduce on Nix 2.3.
I looked a bit into this and I feel like I now understand pretty well the issue. Essentially, the ^out syntax can only work on a derivation, since there is no way to go from an opaque store path for an output to another output. The build worker code already only handles that case (built derived paths always trigger a DerivationGoal, unlike opaque derived paths which trigger a SubstitutionGoal) and I don't think it can realistically handle other cases.
So IMO the correct fix here is to fail at parsing time and require that the base path of a built derived path can only be a .drv (StorePath::isDerivation). I couldn't find any documentation for this feature in Nix so I'm kind of guessing at everything here. Your input would be extremely valued :-)
If that fix is ok with you I'll look into 1. implementing it; 2. adding some unit tests.
(I, uh, kind of dispute that "Easy" label on the issue given that I spent 2h30 looking into this :P)
Failing at parse time is definitely the way to go, imo, unless you can think of anything better. Re: documentation, if you're referring to the
^
syntax, it is actually documented, albeit in one of the (relatively…) more useful pages in the manual that's basically linked nowhere: https://docs.lix.systems/manual/nightly/command-ref/new-cli/nix.html#derivation-output-selectionhttps://gerrit.lix.systems/c/lix/+/1151