search

nix-community / fetchTree-spec

A thorough specification and conformance suite for builtins.fetchTree and lock file items [maintainer=@roberth,@flokli,@lf-(invited)]
12 stars 0 forks source link

?dir in URLs #2

Open lf- opened 1 month ago

lf- commented 1 month ago

Various flake metadata has leaked into URLs and we need to specify clearly which things are acceptable for libfetchers to have in URLs.

(note that putting random stuff in URLs is sketchy in-band signaling in the first place, but this is the hand we were dealt sadly)

c.f. us removing ?dir from URLs in https://git.lix.systems/lix-project/lix/issues/472 and causing a regression

n.b. I am filing this issue so I don't forget, but I am currently taking a break from Lix things as I am quite burned out.

roberth commented 1 month ago

Good clarification, let's include something like that. Wishing you a good recovery.

Not in scope: pointers into whole sources, such as `"${src}/foo"`. In scope, but not implemented yet: fetching a subpath, such that its parent directories need not be fetched/hashed/included. (We'll find better phrasing for this)
lf- commented 1 month ago

Ah, no, I am explicitly complaining about ?dir in URLs, which is flake stuff that should have never been going into libfetchers to begin with! We removed it in Lix and it caused CppNix to start re-locking flake lock files generated by Lix (which is a huge beef I have with flakes' implementation [you cannot have another implementation generate lock files since they will be relocked if the wind is going the wrong direction] and a reason I am personally wishing I never have to touch their internals again; this stuff is so insanely fragile, and I would really like it to not be stabilized in anywhere near the current form).