On Mar 12, 2014, at 15:32 , Zach Beane <x...@xach.com> wrote: > Robert Goldman <rpgold...@sift.net> writes: > >> Zach Beane wrote: >>> The complexity of the registry configuration is one reason why I added >>> the ~/quicklisp/local-projects/ mechanism. >> >> Right, so I don't see why there's such a huge objection to having a >> similar mechanism for ASDF. Stellian suggests using >> ~/quicklisp/local-projects/. So why is it wrong for ASDF to have a >> local-projects directory? >> >> All I am suggesting is to have the local projects directory for ASDF be >> visible, instead of invisible. >> >> I stand corrected about using a name that the user might have already >> had (thanks, Pascal!) but I don't yet see a solution that's as easy as a >> default directory location. > > I think having a similar mechanism would be good. (And the > loading-from-a-file thing could be nice too.) > > I think the main problem is that giving it a nice name means that the > chance is high of it clashing with a nice name one or more users is > already using. > > A while ago I was thinking it would be nice to have an API like this: > > register-system-directory directory &key permanently > > Registers DIRECTORY as a directory to search for system files. If > PERMANENTLY is true, make the registration persist across sessions.
> But then I got hung up about how to make PERMANENTLY work -- I don't > think there's any way to ask ASDF what directory is suitable for saving > a config file. > > And I am 100% in favor of a nice solution that does not involve > Quicklisp. The simpler, the better. That is what MK:DEFSYSTEM used to (actually still does) have. mk:add-registry-location <pathname> I don’t think you want the ‘permanently’. Your init file should be able to deal with that. -- Marco Antoniotti
