Found in ‘Show and tell’ on the Racket Discourse server:
Hm. This doesn’t always work. On another machine, (collection-search '(lib "lib/lib.scrbl")) finds “lib/lib.scrbl” in a package in the same collection, except that file doesn’t exist in that package at all.
Using this first command instead seems to work better scribble --dest ./build --dest-name lib --htmls --info-out build/lib.sxref +m --redirect-main "<https://docs.racket-lang.com>" `racket -e "(display (path->string (collection-file-path \"lib.scrbl\" \"lib\")))"`
Is it expected that collection-search can return a path that doesn’t exist?
Probably you should avoid using display programmatically
I might use write-string there
That wouldn’t work; the length of the string would end up as part of the path. Why not use display?
Display is intended for human readability, so it may make wrong choices for programmatic consumption
Eg, handling of newlines
Noted. If there are newlines in the path I’ll deal with it then :stuck_out_tongue:
Ahh (void (write-string …)) works
I think it doesn’t even look at the content of the paths that it produces
Is there a reason not to use collection-file-path?
not as far as I know; i just discovered collection-search first
I’m using collection-file-path now; it just seemed odd that collection-search could generate a bogus path.
perhaps a naive question: I’m building scribble docs on WSL, using my Windows installation of Racket. Is there a way to force Scribble to use Unix (i.e. case-sensitive) paths? Or, is there a way to have a path->string/convention sort of function, that I could ensure produces Unix-convention paths?
I’ve checked the Manipulating Paths section of the docs as thoroughly as I can, and don’t see any way to get this behavior
the paths I need are simple, relative dir/dir/dir/file.foo sorts of things, so I suppose I could just string-substitute \ with / and call it done…but that seems brittle/incorrect
Are the relevant paths in generated HTML or somewhere else?
Does (system-path-convention-type) return 'unix or 'windows under WSL?
Maybe (system-type)?
From WSL, you can run either a Windows build or a Linux build (so, 'windows or 'unix, respectively). My guess is that @blerner wants a Windows build for DrRacket, at least.
I have a Windows DrRacket installed, and if I can avoid installing a second racket within WSL, so much the better
the relevant paths are generated by install-file, part of the html-renderer of scribble — though I have a bit of a wrapper around that method, since its handling of dest-prefix isn’t quite what I want (and that behavior apparently changed between v8.2 and v8.3, so I needed to go fix up my wrapper…) because it’s a Windows build of DrR, the paths have \ separators in them, which then make it into the generated HTML. but since the generated HTML is going to live on a Linux machine eventually, I (a) needed to re-process the generated paths to be case-sensitive, and (b) wanted to fix up those path separators
(the case-*in*sensitivity happens automatically within the base-renderer, which simplifies paths. I happen to know that my directories are lowercase but my filenames might not be, so I can just redo the filenames as needed)
(system-path-convention-type) returns ’windows
Are the generated paths in HTML absolute or relative? I’d expect only absolute paths to use \.
relative
That sounds like a bug. I can imagine how install-file might go wrong that way, if that’s it. So, Scribble is trying to generate a reference to a file (that you asked it to add?), and it’s generating a relative URL with \?
My overall scenario is, I have a project src-root directory and a dest-root directory, and I want the build to install-files such that their paths relative to dest-root match their paths relative to src-root. So I added a wrapper around the install-files method that manipulates the dest-prefix state within the render a bit, and then calls the superclass’s install-files. (This was something that versions < 8.2 couldn’t do at all, AFAICT, and the dest-prefix stuff in v8.3 doesn’t quite do what I think it does; if I’m misunderstanding it, that’s entirely possible…) But the result of the super-call gives a relative path with \ separators in it
If I run scribble --dest-base nested/ ..., on Windows, then the paths in HTML to support files end up with nested\ instead of nested/ (which is broken). That’s the problem you’re seeing, right?
I suspect so, yes. I’m not currently using --dest-base at the command line, directly, but I think that’s what I’m seeing
It does seem like you can work around the bug by overriding install-file. When you get a string back, use split-path to break it into a list of components, use path-element->string to turn each element into a string, and hthen join the strings with a / separator. You may have to deal with 'up and 'same path components, but probably not.
Meanwhile, I’ll fix the bug.
right, that’s ultimately what I’ll probably do. I was wondering if there were a more robust way of “format this #path as a Unix path string” besides “I’ll just manually insert all the /s”
There may be a relative-path-to-relative-url function somewhere. Seems like there should be, but I don’t remember.
oho, yes — relative-path->relative-url-string is such a thing
Yes, I just found that, too :slightly_smiling_face:
that’s intriguing…
that does seem to work for my case. thanks!
(hehe, looking at the implementation of that function…it just explode-paths the path and chunks it together with / — nothing super fancy :slightly_smiling_face: )