Should `compile-op` bind `*package*` to CL-USER?
I'm working with some packages that do not `(:use :cl)`, and compiling some systems which have bare, non-package-prefixed `defpackage` forms. (Sadly, I haven't convinced people to use `uiop:define-package` yet, as the SBCL distributed version doesn't have `:local-nicknames` support :disappointed: .) When my REPL is `in-package :SOME-PACKAGE-THAT-DOESNT-USE-CL`, doing `asdf:load-system` to compile and load a file like: ``` (defpackage #:foo ;; some defpackage clauses ) (in-package #:foo) ;; some code or whatever ``` fails with an error, because the `defpackage` form reads as `some-package-that-doesnt-use-cl::defpackage`, which is assumed to be a call to an undefined function, `#:foo` is treated as a read from a variable, and everything falls apart. What's worse, I can't just `in-package :cl-user` at the repl and then re-run the `asdf:load-system`, because the compiled fasls are cached, so I have to change back to a cl-using package and then `asdf:load-system` with `:force t` or `:force :all`. The obvious solution, in my mind, is to have the `perform compile-op lisp-source-file` method locally bind `*package*` to `cl-user`, with the assumption that either: - The file intends to use `in-package` to specify the package it actually should be in, or - The file expects to be compiled in the default package, i.e. `cl-user`. Probably this local binding should be put in place outside of `call-with-around-compile-hook`, so that it's still possible to use `:around-compile` to locally bind `*package*`. (I hope no one does that, though. Ew.) Would this break anything?
issue