I am on nixos-unstable and after an update last Monday I noticed that Racket didn’t find the documentation.
> (require racket/help)
> (help map)
Loading help index...
; help: no documentation found for: map provided by: "/nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/collects/racket/base.rkt"
; Context:
; /nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/collects/racket/repl.rkt:11:26
Also, weirdly:
my-test.rkt> (help)
Sending to web browser...
file: /nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/doc/index.html
Turns out this file does not even exist on my machine, but /nix/store/za0k7s00bg3v5sasyqalv12ii7pxjbjn-racket-7.6/share/doc/index.html does! (mind the added share/)
I am not sure whether this breakage has any connection with the update however. I bumped into it while trying to debug Racket Mode for Emacs not being able to find the documentation any more (GitHub issue). This used to work before the update, but both Racket and Racket Mode got updated, so the breakage can be in many possible locations.
Does anyone have similar issues with Racket?
Quite weirdly, installing and requiring (importing) packages works smoothly. It almost looks like the version of racket/help I have does not match that of the Racket distribution.
I just had a quick look. The 7.6 bump definitely broke that.
The problem comes from the tarball we’re using. Until the 7.6 release, the documentation was at the root of the tarball. It is now sitting under /share/doc.
I’m not sure whether we should move the doc to the root during a fixup phase or whether we should patch racket to lookup at ${store_path}/share/doc instead of ${store_path}/doc…
Thanks a lot @picnoir ! It’s really reassuring that you identified the cause of the issue. I started digging into the source code of racket/help to see where it looked for docs, and you saved me even more digging.
I’m not sure whether we should move the doc to the root during a fixup phase or whether we should patch racket to lookup at ${store_path}/share/doc instead of ${store_path}/doc …
Naively, I’d say that patching Racket is better than moving the doc. I haven’t yet looked at the Racket Nix package (although now it seems obvious I absolutely should have ) , but I suppose it already patches the lookup paths. Updating that path seems better than moving doc out of shareand still patching Racket.
Naively, I’d say that patching Racket is better than moving the doc. I haven’t yet looked at the Racket Nix package (although now it seems obvious I absolutely should have ) , but I suppose it already patches the lookup paths. Updating that path seems better than moving doc out of shareand still patching Racket.
We are not patching racket per say, we are setting up autotool’s prefix
to $out. This prefix appended by /doc is used by racket as a default
doc-dir[1]. This doc-dir is then used by the builtin help function.
100% agree with you, it makes more sense to point racket to the
/share/doc directory.
I wrote a small fixup phase patching the default $out/etc/config.rktd to
point doc-dir to $out/share/doc. I’m currently re-building the whole
world. I’ll open a PR as soon as I’m sure this small trick is corretly
working.
I also got an answer on the Racket Users mailing list here. Essentially, the problem seems related to this GitHub issue: it seems that the new packaging for Racket 7.6 breaks “old unixstyle install default behavior”. The suggested workaround before this gets fixed upstream is here:
Do you think we should rather go with this suggestion? I’ve been running Nix and marginally contributing to Nixpkgs for a couple years now, but I don’t really have an opinion about how this fix compares to your solution.
Great! Uknowingly, I was looking for exactly this when I was trying to debug the problem on my side.
In the end, I came up with this dirty hack yesterday night:
That said, that’s nowhere from an acceptable fix, it could break at any
moment.
I was really confused by this:
How come racket was not looking at $prefix/share/doc for the build? I
did not manage to find an answer to that, did not open a PR and went to
bed angry.
In light with the issue you just linked, everything now makes sense.
Provided we’re not enabling the “unixstyle” build, we end up in this
block:
Indeed, looks like enabling the unixstyle flag is the right thing to do here!
I’ve been running Nix and marginally contributing to Nixpkgs for a
couple years now, but I don’t really have an opinion about how this
fix compares to your solution.
It makes much more sense than my dirty hack! Please open a PR!
I asked the author of that fix to submit a PR, as they already have a branch with exactly this fix in their fork of Nixpkgs. I’ll also test this fix in my local checkout of Nixpkgs just in case.
Thanks a lot for your work @picnoir ! I hope you managed to sleep well anyway
) , but I suppose it already patches the lookup paths. Updating that path seems better than moving 
