Work-around built-in ~/common-lisp/ in search path?
Robert Goldman
rpgoldman at sift.net
Wed Nov 16 18:53:24 UTC 2016
On 11/16/16 Nov 16 -12:44 PM, Jason Miller wrote:
> Does specifying a registry with :ignore-inherited-configuration not
> work?
I could do that, but I that would also delete
system-source-registry
system-source-registry-directory and
default-system-source-registry
... which I feared might cause me access to bundled SBCL libraries.
That's why I was wondering if it would be helpful to have something like
:ignore-user-default-directories
and
:ignore-system-default-directories
Best,
r
> On 12:01 Wed 16 Nov , Robert Goldman wrote:
>> Here's my issue:
>>
>> 1. I have a bunch of lisp libraries that I use on everyday things
>> installed in ~/common-lisp/. One of the systems in there is an older,
>> modified version of fiveam that my company uses in many projects.
>>
>> 2. I have a project where we use libraries from quicklisp to make it
>> easier to handle dependencies. For this project, I run a function that
>> resets the ASDF source-registry, and uses a special copy of quicklisp (a
>> copy that writes its systems in a different location).
>>
>> 3. I cannot build my system because the version of fiveam in
>> ~/common-lisp/ shadows the version of fiveam from quicklisp, which I need.
>>
>> 4. I don't see any OBVIOUS way to tell ASDF to ignore my ~/common-lisp/
>> directory. I can do the following:
>>
>> (setf asdf:*default-source-registries*
>> (remove 'asdf/source-registry::default-user-source-registry
>> asdf:*default-source-registries*))
>>
>> but that seems really hard-core. Would it be reasonable to make the
>> defaults a little easier to override?
>>
>> Maybe something that's equivalent to --no-userinit and --no-sysinit when
>> starting lisp -- something that will remove the user-specific entries or
>> system-specific entries, respectively?
>>
>> I don't believe I can simply wipe the defaults, because then I might
>> miss some SBCL libraries that come with the system default settings.
>>
>> Cheers,
>> r
>>
More information about the asdf-devel
mailing list