Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

?dir in URLs #2

Open
lf- opened this issue Oct 22, 2024 · 2 comments
Open

?dir in URLs #2

lf- opened this issue Oct 22, 2024 · 2 comments

Comments

@lf-
Copy link
Collaborator

lf- commented Oct 22, 2024

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
Copy link
Collaborator

roberth commented Oct 22, 2024

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-
Copy link
Collaborator Author

lf- commented Oct 23, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants