When I upgrade Racket versions, the leftover .zo files are the wrong version and most operations will use them and then error out. Is there any option or tooling to convert them or clean them up (short of running a clean script)?

Oh.. I could have my initial operations ignore compiled files.

I think the consensus is to run something like find . -name compiled \| xargs rm -rf

Yeah, I’ve avoided special commands because this is an end-user workflow that does the same thing all the time…. I’m having them upgrade Racket which will be enough drama already, lol.

Those .zo files are absolutely critical for basic performance… this failure mode is… vexing.

Seems like detecting a version mismatch in the zo and recompiling would be easy, so it must not be

Yeah, probably. It’d be a biggish project for sure… but it would be nice to be able to either a. package up a compiled package and distribute it without needing source (preferably in a .zip file) or b. have the normal read-eval for .rkt files be able to handle missing or out of date .zo files (or incorrect versions.

I looked into a. a long time ago but never went anywhere with it…

For b see the custom-load package:https://docs.racket-lang.org/custom-load/index.html\|https://docs.racket-lang.org/custom-load/index.html

For a that’s what raco exe is for

I’ll have to investigate raco exe… for the custom-load package that doesn’t seem promising since I get version mismatches during raco make. Would I be able to skip the raco make step entirely?

Oh if you’re getting the version mismatch in raco make that’s more surprising

Also, raco setup will fix things more comprehensively if the code is all in collections

I think part of my issue is that despite being in a collection, I have multiple “root” .rkt files and need to begin the recursive setup/make at each root

If it’s a collection then raco setup that-collection should do the trick

Cleaning can also be done with raco setup -c

ah, and -K will cause it to stop recursing into dependent installed packages