scymtym
commented
1 year ago Thank you for the suggestion but I'm not convinced the suggested change would be an improvement. I don't want this to turn into a long discussion, but since i use the style employed in the system definition of this library in other libraries as well, a proper explanation seems in order.
As an initial remark, I'm basing my current practice on the following description: https://github.com/fare/asdf/blob/master/doc/best_practices.md#trivial-packaging. This sub-section generally makes sense to me although I find it a bit strongly worded.
By starting an ASDF system definition file with
(in-package #:asdf-user), you gain two advantages. First, programming tools will be informed that this is the right package to use in order to interpret the file contents.
I can see this point for some kind of basic analysis. However, based on the description referenced above, it seems just knowing the package would not suffice. Maybe ASDF binds other special variables or changes the readtable.
As a result, I assume a more robust approach to analyzing system definitions would be treating .lisp and .asd files differently and explicitly establishing the correct environment for each. For ASDF, it seems, unfortunately, like this would entail reverse engineering what the correct environment actually is (Well, to be fair, this might be documented somewhere, I haven't really looked).
Second, if the ASDF file is not in a place where ASDF can find it, the programmer can then use
LOADto load it, without updating the places ASDF is looking. This last point is especially useful when there are two versions of the system in the system, for instance one in Quicklisp to be used for "production" and one that is used for development or experiments.
The referenced description states that cl:load must not be used to load system definition files. Instead, it prescribes the use of asdf:load-asd. I don't know what the problems with cl:load are, but I always use asdf:load-asdf and it has worked fine so far.
For a more convenient way to evaluate such "free standing" system definitions, SLIME's C-c C-k (but not the form-level evaluation commands) can be used. traceing asdf:load-asd confirms that SLIME's C-c C-k calls asdf:load-asd so that everything works.
So in summary, the recommended practice has worked well for me and seems, from my point of view, to address the concerns you raised. Let me know what you think.
robert-strandh
By starting an ASDF system definition file with (in-package #:asdf-user), you gain two advantages. First, programming tools will be informed that this is the right package to use in order to interpret the file contents. Second, if the ASDF file is not in a place where ASDF can find it, the programmer can then use LOAD to load it, without updating the places ASDF is looking. This last point is especially useful when there are two versions of the system in the system, for instance one in Quicklisp to be used for "production" and one that is used for development or experiments.