[asdf-devel] Reader conditionals in :depends-on considered harmful?

[Faré]

My recommendation is to not use reader conditionals, but instead use
  asdf/find-system:register-preloaded-system

Quicklisp will preempt any preloaded-system, but if that's what you
want to avoid, my recommendation is to push the equivalent of the
sysdef-preloaded-system-search before quicklisp's equivalent, but
after the source-registry or the quicklisp local project search. Ahem.
This can be tricky indeed.

And yes, if you don't ship with asdf and/or quicklisp and/or a way to
load them that will actually be used, you lose. That said, I don't
know about quicklisp, but I see no reason against pre-loading asdf,
beside the slight increase in heap size: it's not going to hurt if
it's not used, and it is designed to be able to upgrade itself and
avoid downgrading itself, so that should be safe.

Speaking of which, currently, upgrades unregister loaded systems,
though they probably shouldn't if the upgrade was from a recent-enough
version where the class definitions and generic function definitions
haven't changed in incompatible way. Robert: you might want to look
into that, though doing it right requires a lot of testing. I suppose
ASDF 2.27 would be the oldest fully compatible version at the time
being.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If you think you can do a thing or think you can't do a thing, you're right.
        — Henry Ford


On Sat, Dec 7, 2013 at 10:57 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
> Dave Cooper wrote:
>>
>> Hi,
>>
>> Is stuff like the following advised/recommended?
>>
>> ;;;;;
>>  (asdf:defsystem  #:robot
>>   :description  "The Gendl™ Simplified Android Robot example "
>> ...
>>  :depends-on (#-gendl :gendl)
>> ... )
>> ;;;;;;
>>
>>
>> The scenario is that we ship a pre-built Gendl image which has no asdf
>> or Quicklisp in it (but does, of course, have :gendl included in
>> *features).
>>
>> Downstream user is then free to load Quicklisp and start pulling in
>> libraries. But if they pull a library (or application, like :robot),
>> which normally should depend-on :gendl, then we don't want it trying to
>> reload the whole gendl system, since it's already built in.
>>
>> I know this was discussed here briefly around the launch of 3.0.3 but
>> I'm still not completely clear on how it should work. If we don't
>> include ASDF and Quicklisp at all in our pre-built image, then I don't
>> see any way for us to tamper with e.g. asdf's registry search functions.
>> I guess the only way to do that would be to provide a custom function
>> for installing Quicklisp and ASDF -- but we have no guarantee that the
>> user will actually follow our function and not simply try to install
>> Quicklisp according to the instructions at quicklisp.org
>> <http://quicklisp.org>.
>
>
> I think it's fair to say that there are differences of opinion about this.
>
> One school of thought would deprecate these, favoring a declarative
> syntax for ASDF:DEFSYSTEM.  They wouldn't like such use of reader macros
> because it "hides" information from ASDF.
>
> I am of a more pragmatic school that thinks these are fine.  While I
> like declarative systems when possible, I'm not convinced that they are
> always realizable.  I have a case very similar to yours where I have
> done exactly the same thing and put a #-<system> <system> in
> :depends-on, because ASDF does not correctly detect that <system> need
> not be reloaded in the prebuilt image we have.  It's particularly an
> issue for us since the system in question *cannot* be loaded twice: if
> you attempt to do so, it compromises the state of the lisp image so that
> it is no longer usable.
>
> cheers,
> r
>