Right now prefixing a path with a leading "/" does not have consistent behavior. One thing that especially bothers me is that links do not get any attention from our "turn paths to relative paths" mechanism that is applied to media elements.
Right now we consider paths without a relative prefix (no ./or ../) to be leading from the project root:
images/image.png gets treatment, /images/image.png gets this too when linked in a media-element, but in a meta variable the latter sometimes fails:
logos:
- '/images/logo.png'
gets no conversion while
logos:
- 'images/logo.png'
does.
In addition the path images/image.png is ambiguous in terms of file-path-syntax: Does it reference the file in /images/image.png or /decks/images/image.png if used in a file inside /decks/?
Curious enough re-adding the logos variable to the runtime-path-variable inside the decker.yaml makes the first version work even though the list of runtime-path-variables does not change. I already presented this bug to @monofon .
I doubt there is ever a situation where one would link to a file in their linux-system-root or wishes to reference something from the web-root of their host. At least these are the situations where a "/" prefix would have a different meaning than "reference a file relative to the project root".
EDIT: I just thought of a situation where one would actually reference a file outside of the project root: Whenever a meta-variable references an external executable, like whisper.cpp's main.
I propose that every URI, be it in a meta variable, a media element or a link that begins with a "/" gets our "relative path treatment" and references a file starting from the project root.
Right now prefixing a path with a leading "/" does not have consistent behavior. One thing that especially bothers me is that links do not get any attention from our "turn paths to relative paths" mechanism that is applied to media elements.
Right now we consider paths without a relative prefix (no
./
or../
) to be leading from the project root:images/image.png
gets treatment,/images/image.png
gets this too when linked in a media-element, but in a meta variable the latter sometimes fails:gets no conversion while
does.
In addition the path
images/image.png
is ambiguous in terms of file-path-syntax: Does it reference the file in/images/image.png
or/decks/images/image.png
if used in a file inside/decks/
?Curious enough re-adding the
logos
variable to theruntime-path-variable
inside thedecker.yaml
makes the first version work even though the list of runtime-path-variables does not change. I already presented this bug to @monofon .I doubt there is ever a situation where one would link to a file in their linux-system-root or wishes to reference something from the web-root of their host. At least these are the situations where a "/" prefix would have a different meaning than "reference a file relative to the project root".
EDIT: I just thought of a situation where one would actually reference a file outside of the project root: Whenever a meta-variable references an external executable, like
whisper.cpp
'smain
.I propose that every URI, be it in a meta variable, a media element or a link that begins with a "/" gets our "relative path treatment" and references a file starting from the project root.
Examples:
index.md
/decks/introduction.html
/decks/advanced.html