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
Implement support for percent encoded filepaths for flakerefs #6614
Conversation
274af6c
to
654927c
Compare
Having another look at it, I'm a bit confused by the semantics: if Also, can you add something to the release notes for this? |
These are my intended semantics at least. IMHO, users expect command-line tools to work with paths by default, and that is what they should do. If the user supplies something like
Done :D |
Yes that kinda makes sense indeed… at least I can think of any better semantics. @edolstra any thought on that? |
Any update on if this can be merged? I was just hit by #6394 my first time trying to set up a flake-based project dev shell. |
Yes, I think it can, sorry about the long delay @RasmusRendal. There are a few conflicts now, do you mind resolving them? |
@RasmusRendal, are you still working on this PR or should someone take it over? |
Yeah I don't think I'll have the time in the immediate future to get into the Nix codebase again. If somebody else would solve the merge conflicts, that would be very nice of them. |
Ok, thanks for letting us know 👍 Unless someone is willing to beat me to it I can take over that one as it's an important fix (and also probably fixes #5759 which is of the same vein). |
src/libexpr/flake/flakeref.cc
Outdated
else if (std::regex_match(url, match, pathUrlRegex)) { | ||
std::string path = match[1]; | ||
std::string fragment = percentDecode(match.str(3)); | ||
else if (pathExists(url.substr(0, url.find("#")))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some notes (for myself mostly) on that change since it's a fairly crucial one:
- The
pathExists
call is potentially problematic because the flakeref should exist independently of what the filesystem contains. Maybe we could just split unconditionnally regardless of whether the path exist - Splitting on
#
is probably not enough since the syntax of a path flakeref is of the form<path>(\?<params>)?(#<fragments>)?
. So we'll want to split on?
too - I guess this isn't truly correct if multi-byte utf8 glyphs can contain
\63
(the ascii code for?
) since we'd just split here. I think this isn't the case (precisely to allow this kind of things), but even if it's the case, it's probably better than the current situation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if multi-byte utf8 glyphs can contain \63
I don't think they can, utf8 is carefully defined that the ascii bytes are only used for the coresponding character. All the other stuff has the highest bit set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may need some user-visible documentation in the flake references section. One sentence and an example should be enough.
I started giving it a shot, but it turns out that the documentation for plain path flakerefs ( Since rewriting that doc would have a slightly bigger scope, I'd be in favor of merging this PR first and fixing the docs later. Does that sound good? |
Yeah, I can live with a lower standard of documentation quality for experimental features. |
Rebased to fix a couple benign conflicts. With #8640 being out of the way, this one should be good to go |
Would love to get this rebased and merged! The bug described in #6394 with spaces caused me quite the headache this morning! I'm somewhat new to Nix and loving it so far, but it's little things like this that really drive people away when the point of a tool is automating away other tooling problems! |
@fricklerhandwerk would you care to give this another look? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the back and forth, but it was really unclear to me what this changes. If I understand it correctly now, we can simplify a lot.
Support using nix flakes in paths with spaces or abitrary unicode characters. This introduces the convention that the path part of the URL should be percent-encoded when dealing with `path:` urls and not when using filepaths (following the convention of firefox). Co-authored-by: Rendal <rasmus@rend.al>
Was starting to be very complex and hard to follow. Now the different cases should be easier to understand.
@fricklerhandwerk I gave the documentation and release notes another pass, PTAL. If that's still not clear, I'd like to take ½h or 1h to pair with you on it so that we can get this through and not have it wait forever |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot, makes sense now. Slight grammatical fixes, otherwise good to merge.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Might just be a CI issue? Quite literally ran for an hour.
|
To support using nix flakes in paths with spaces, this introduces the convention that the
path
part of the URL should be percent-encoded when dealing with paths, and that it's the responsibility of fetchers that use a local path to decode it.It follows the convention of firefox, which uses percent encoding when encoding a local path to an URL.
Eventually, this might also allow paths with arbitrary unicode characters (#4563, #5759), if the percent encoding and decoding methods are improved such that they can handle them.
This closes #6394.
I can get rid of the hijacked test if you'd prefer it.