%<...>% path expansion notation #2927
Conversation
There are many occasions in packaging of the form
%{some-directory-variable}%/more/path/components which result in an
amateur/confused-looking mixed back/forward-slash path on Windows.
String interpolation is extended such that %<subst>% has subst expanded
with / converted to the path separator for the OS. %{...}% may be nested
inside %<...>% notation, allowing normal variables to be used within a
path expansion. Thus %<%{lib}%/stublibs>% is expanded to the value of
lib with "\\stublibs" on Windows.
Signed-off-by: David Allsopp <david.allsopp@metastack.com>
|
This will obviously also require a docs update, but I'll do that after the notation is agreed! |
| let expand_string ?(partial=false) ?default env text = | ||
| let default fident = match default, partial with | ||
| (* Resolves ["%{x}%"] and ["%<x>%"] string interpolations *) | ||
| let rec expand_string_aux ?(regex=path_interp_regex) ?(partial=false) ?default env text = |
There was a problem hiding this comment.
Note that the use of ~regex means that this only introduces one recursive call - expansion of %{...}% within %<...>%. It doesn't add recursive expansion of variables by accident!
|
This is going to make things unreadable and people will always forget to do it. Why doesn't opam simply converts path variables to forward slashes on all platforms ? Consumers of these paths can then do the right thing according to the platform (e.g. by using a suitable path library). |
|
I share some of @dbuenzli's concern, in particular about forgetting to add the delimiters. I am not sure it's wise to limit the expansion to forward slashes when it will be consumed by Windows commands, though, but I don't really have a good grasp of how this ends up being handled on Windows. Since these strings are used as arguments to arbitrary commands, we have no way of knowing wether they are paths or not, so the only two solutions I can imagine (if dropping backward slashes altogether, like @dbuenzli suggests, is not a viable solution) are:
|
|
I am virtually certain both from a presentational and technical perspective that forcing forward-slashes on Windows is a mistake (even if a mistake made by a lot of other "cross-platform" projects) and we should be sticking to the actual convention. As a tiny bit of background, while there are various layers of compatibility, the separator at the kernel level is backslash only (it is API functions which do the conversion, but that's at the subsystem level). More relevantly, there are quite a few user-level places where forward-slashes do not work (and these are not particularly well-defined places - i.e. there are shell commands where some forward-slashes work and others do not). Most importantly, there are no places where back-slashes will not work and you have to use forward-slashes... Some further thoughts on both comments:
|
This misses my point. I think that your proposal introduces a complexity that we could eschew. More specifically here's what I think should be done.
Now you may see 1. as already being a heresy but I think it's will make our life simpler without adding more idiosyncrasy to the already confusing |
|
For me, it escapes heresy by not requiring or displaying the forward-slashes! Actually I think we're in closer agreement than I possibly realised, but I'm not convinced that a key part of (1) is presently doable (@AltGr may have a different opinion). The problem is that there is no actual notion of a "path variable" (at present) - that's partly what this syntax introduces, though it's of course not the only way. Storing forward-slashes internally also shifts considerable complexity back into opam itself. While it would still add complexity to the language, @AltGr's suggestion of a whole string qualifier would at least get rid of the commonplace Overall, I'm afraid I see as requirement what you see as idiosyncrasy. It's also potentially a big (though not insurmountable) ask to expect all build systems (or, in general, commands being executed) to convert the forward slashes (shell invocations, where necessary, become harder - there are build systems, such as nmake, which cannot cope with them. |
The log of invocations would still be heretical.
Aren't the
You don't store them forwardly. When you perform substitution in the |
No, the variables are only booleans or strings at the moment. Besides, that could trigger changes within the variable expansion, but not for the rest of the string, e.g. in the right part of I still only see "forward slashes everywhere" or "'/' is a special char meaning |
I dislike both, especially the second. Isn't If we want that to be more obvious we could use any other character that is not allowed in variable names, e.g. |
|
@dbuenzli I thought "forward slashes everywhere" was what you initially suggested ? |
No I suggested 1. + 2. + 3. Now since it seems you don't have the information internally about what is a path and what is not it seems that if we have 1. we cannot have 3. which I see as an ux issue. |
AltGr
added
the
PR: OUTDATED
|
Note: we are now attempting to lock the opam file-format (https://github.com/ocaml/opam-file-format/) to allow for tighter integration with dune... so we should consider this shortly if something is to be done. |
|
This is resolved in a much more principled, elegant and less syntactically-invasive way in #5636 🥳 |
There are many instances in packaging of the form
%{some-directory-variable}%/more/path/componentswhich result in an amateur/confused-looking mixed back/forward-slash path on Windows.I propose adding the notation
%<subst>%such that subst is expanded with/converted to the path separator for the OS.%{...}%may be nested inside%<...>%notation, allowing variables to be used within a path expansion. Thus%<%{lib}%/stublibs>%on Windows is expanded to the value oflibwith\\stublibsappended.