2009/5/13 Robert Goldman rpgoldman@sift.info:
I remain confused on "what installer" -- but nevermind.
I was also thinking "eugh" in response to that alternative. So I
Just the be clear, the "eugh" did not apply to the first option, which seems the most natural one to me.
figured it might be desirable to allow an installer to take an upstream library, together with its .asd file, and modify only his/her version of find-system so that when <library>.asd was loaded, we would also look for (for example) <library>.install or <library>.config, and load those right after the .asd file to impose any necessary site-specific configuration.
I'm opposed to adding number of files responsible for the behaviour of the system as long as there are alternatives. They make debugging harder, and test case reproduction doubly so -- especially when they can contain arbitrary code.
That said, I think perhaps adding umpteen methods to TRAVERSE is not the right hammer here. Maybe a *READ-ONLY-SYSTEMS*, list, which it would be easy to push things onto.
Alternatively, if complex configuration is wanted, I would propose a hash-table mapping system names to asdf:configuration objects, and a DEFINE-SYSTEM-CONFIGURATION macro to populate it -- population would be done in initialization files (or lazy-loaded files via some hook if one really has to.)
Cheers,
-- Nikodemus