I used the information in the Tutorial: Contributing to Racket to install a local forked clone of the Scribble repo into my pre-compiled installation of Racket, via
I fooled around with the Scribble source for a bit, but then decided I was following the wrong path. There's a lot I don't like about Pollen, but it is certainly more flexible than Scribble. So, I want to go back to the standard distributed package for Scribble.
I tried
$ raco pkg update --unclone scribble
which claimed to be un-installing and re-installing scribble. However, the --html-nav option I added to Scribble's command-line is still working, so I'm apparently still using my cloned version of Scribble.
I next tried
$ raco setup scribble
which did a bunch of stuff, but I'm still running my modified source for Scribble.
Do I need to trash my Racket installation and reinstall from scratch?
I can imagine a couple of different things going on here, up to and including the possibility that your command-line path is still finding a binary you created as part of your work, even though racket is correctly looking at the original.
Welcome to DrRacket, version 8.13 [cs].
Language: racket, with debugging; memory limit: 128 MB.
#<path:/Applications/Developer/Racket v8.13/share/pkgs/scribble-text-lib/scribble/main.rkt>
>
smb % which scribble
/Applications/Developer/Racket/bin/scribble
smb % ls -l /Applications/Developer/Racket
lrwxr-xr-x 1 smb admin 36 Jun 23 13:47 /Applications/Developer/Racket -> /Applications/Developer/Racket v8.13
and I am definitely still running something built from my source at /Users/smb/GitHub/scribble. In particular it is including my modified version of scribble-lib/scribble/run.rkt and my new scribble-lib/scribble/xexpr-render.rkt.
This isn't a big deal for me, though, as I'm back to actually making some progress with my modified renderer, and reinstalling from scratch isn't a big deal if I decide to give up on it.
II think the issue is that --unclone scribble doesn't also unclone all the other packages that --clone offered to switch into the clone for you. The auto-conversion convenience currently only works in the cloning directionl probably it should be improved to work for --unclone.
You could unclone the previously converted packages individually with --unclone scribble-lib, --unclone scribble-html-lib, and --unclone scribble-doc.
Meanwhile, the collection-file-path check turned out to be misleading, because scribble/main.rkt happens to reside in a package that is not referenced auto-converted to a clone. Maybe auto-conversion missed it because the package is not immediately referenced by scribble (only via scribble-lib), but that seems like a bug.
On further investigation, I see what I was missing:
There's an "implies" spec on "scribble" to "scribble-lib" and "scribble-doc", and "scribble-lib" has an "implies" for "scribble-html-lib". That's why those three packages are the ones that were converted: only those packages are shifted to a GitHub-based package source at the --catalog step. The other packages kept their sources that refer to release-time snapshots, instead of GitHub, so they weren't considered cloning candidates.
There's already support for auto-conversion back to non-clones. The problem is that when --unclone is used without --catalog, the package source for "scribble" resolves back to a non-GitHub source, and the connection to a shared GitHub source is lost. Using --catalog again with --unclone offers to unclone the packages, but then they're all still using the package catalog source and not the release source.
I'm not sure why --unclone without --catalog didn't follow "implies" to change package sources back, so there's still that to look into. And it certainly would be nice to improve the initial step somehow to find all the relevant packages.