`raco pkg migrate` for `--link` and `--no-setup` packages

Questions & Answers
,
1

  1. How does raco pkg migrate handle linked packages (those originally installed with --link from a directory package source)?

    Does it:

    • Copy (ala --copy), such that the original's compiled remains in the original link source dir, and the current version gets its own, fresh compiled?

    OR

    • Re-compile the original link source dir in-place? (Meaning there's still just one compiled, and attempting to use the package with various versions of Racket could give "link: module mismatch" errors.)

  2. What if someone originally installs with raco pkg install --no-setup? Does raco pkg migrate respect that for the new version's copy, OR, go ahead and do setup?

I could just experiment. But in addition to being lazy, I think it's likely I'll learn more by asking. Like maybe my questions already show some misunderstanding.

Why I ask: I'm contemplating having Racket Mode's back end Racket code be defined as a package, i.e. add an info.rkt. But not a package on the Racket package server. Racket Mode would continue to be an Emacs package, a subdirectory of which has its "back end" process Racket files (and now also an info.rkt).

The idea would be to raco pkg install it as a directory package source, using --link. But maybe it needs to be --copy, ala question 1 above?

And for some users, it's nicer never to compile the Racket Mode back end. Startup is still quite fast, and it simplifies moving around various versions of Racket, no .zo mismatch. So that's background on my question 2. If raco pkg migrate always did setup, I suppose it wouldn't be horrible to tell these users they'd need to e.g. raco setup --clean racket-mode, but, I'd need to know to document that.

2

TL;DR attempt: It seems that Racket packages combine at least two aspects: Installing dependencies, and compiling.

The dependencies aspect seems always desirable for all users.

The compilation aspect is only desirable for some users.

So I guess I'm wondering how to juggle both.

Maybe the answer is something like: "Define two packages. One is 'normal', for the people who want compilation. Another is just a meta package, in the sense of (define compile-omit-files 'all)."

Probably that is the only way to guarantee that various raco setup or raco pkg _ commands don't just go ahead and compile the package anyway?

3

It uses the same mode as the source install. So, if the package was installed with --link before, it will be installed with --link in the migration target.

The --no-setup flag is not recorded, so the migrated package would be set up by default.

It sounds like declaring compile-omit-paths may be the way to go. You could document raco make (and raco make again after migrating) as a way to force compilation.

4

Thanks for the advice! That's a reasonably small step from the status quo, where I provide racket-mode-start-{faster slower} commands to help users do the raco make and clean, respectively.

I'm guessing (define compile-omit-paths 'all) means I can't use that same info.rkt to take advantage of raco setup --check-pkg-deps --unused-pkg-deps to validate the deps. But I can seek some side hack for that. Even it can't be checked automatically on every CI run, and instead needs to be some periodic hands-on involving temporarily editing the info.rkt to check, it should be fine, and would still be a net improvement over the status quo.