On Wed, Nov 6, 2013 at 11:01 AM, Faré <fahree@gmail.com> wrote:

On Wed, Nov 6, 2013 at 10:51 AM, Zach Beane <xach@xach.com> wrote:

...

Mirko Vukovic <mirko.vukovic@gmail.com> writes:

...

I have a system sitting in ~/quicklisp/local-dists and a development version sitting in ~/.../lisp-development/

I would like ASDF to open the latter one. I use asdf:load-system.

I cd to the development directory and start slime there. (asdf:load-system ...) still tries to fetch the version in the quicklisp directory.

One easy way:

(push '*default-pathname-defaults* asdf:*central-registry*)

I disrecommend pushing '*default-pathname-defaults* into the *central-registry* — that makes system loading less predictable, depending on the binding of this variable.

Instead, I recommend pushing an actual pathname object (that may happen to be the current value of *d-p-d* or of (uiop:getcwd), if you insist), so that the value remains well-defined in the face of rebinding of the variable.

Or better, edit your ~/.config/common-lisp/source-registry.conf and register your software there. Or for temporary stuff, export a CL_SOURCE_REGISTRY, or call asdf:initialize-source-registry with a parameter.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Fraud is the homage that force pays to reason. — Charles Curtis

This works for me now (lightly tested): (defun asdf::load-local-system (system &rest keys &key (directory *default-pathname-defaults*) &allow-other-keys) (let ((asdf:*central-registry* (push directory asdf:*central-registry*))) (apply #'asdf:load-system system keys))) (export '(asdf::load-local-system) :asdf) There may be a better name for this function instead of `local'. Thanks to all that replied, Mirko

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org On Wed, Nov 6, 2013 at 3:00 PM, Robert Goldman <rpgoldman@sift.net> wrote:

Faré wrote:

...

I disrecommend pushing '*default-pathname-defaults* into the *central-registry* — that makes system loading less predictable, depending on the binding of this variable.

Instead, I recommend pushing an actual pathname object (that may happen to be the current value of *d-p-d* or of (uiop:getcwd), if you insist), so that the value remains well-defined in the face of rebinding of the variable.

Or better, edit your ~/.config/common-lisp/source-registry.conf and register your software there. Or for temporary stuff, export a CL_SOURCE_REGISTRY, or call asdf:initialize-source-registry with a parameter.

So something like

(DEFUN ADD-SOURCE-DIRECTORY-TO-ASDF (DIR) (ASDF:INITIALIZE-SOURCE-REGISTRY `(:source-registry (:DIRECTORY ,DIR) :inherit-configuration)))

and

(ADD-SOURCE-DIRECTORY-TO-ASDF (uiop:getcwd)) ?

This doesn't *add* the directory to the configuration, but each time overwrites the previous configuration to use this directory, then the rest of the normal configuration from environment variables, configuration files, defaults, etc. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org You should never wear your best trousers when you go out to fight for freedom and liberty. — Henrik Ibsen

...

...

(DEFUN ADD-SOURCE-DIRECTORY-TO-ASDF (DIR) (ASDF:INITIALIZE-SOURCE-REGISTRY `(:source-registry (:DIRECTORY ,DIR) :inherit-configuration)))

and

(ADD-SOURCE-DIRECTORY-TO-ASDF (uiop:getcwd)) ?

This doesn't *add* the directory to the configuration, but each time overwrites the previous configuration to use this directory, then the rest of the normal configuration from environment variables, configuration files, defaults, etc.

Ah. I see that I didn't understand the semantics of :INHERIT-CONFIGURATION. I thought it inherited the *current* configuration, but if I understand your response above, :INHERIT-CONFIGURATION means something more like "recompute the configuration based on the standard configuration inputs (and add anything newly specified)."

inherit-configuration means "inherit from the next, wider, configuration method", as defined in *default-source-registries*: first, from the parameter, then from the environment, then from the user source registry file, then from his source registry directory, then from the system (i.e. unix machine, not lisp system) source registry file, then from its source registry directory, and finally from the implementation default. If you distrust or want to override some of them, you use :ignore-inherited-configuration. Otherwise, by default they all :inherit-configuration and you get everything in a priority order that makes sense (and is also compatible with the XDG standard for configuration). So it's filesystem-spatial, not temporal, inheritance, if you want.

The other alternatives (rewrite your source-registry.conf, reset the environment variables, etc.) all seem to involve smashing one's lisp session and restarting. For an old school person like me, who treats his lisp session like his emacs session, and almost like his reboot cycle, this is somewhat unfortunate. Altering ASDF::*central-registry* doesn't have this same (to me) drawback....

You don't have to rewrite your source-registry.conf for something that's temporary. Maintain your list, and tuck it into the parameter you pass to initialize-source-registry, or push stuff to the central-registry. Re-initializing the source-registry does NOT smash anything about your lisp session; all it does is update where ASDF will find the systems. The only builtin behavior that smashes your session is upgrading ASDF itself — which is why ASDF insists on doing it as the very first thing when you load a system, so that cannot happen in the middle of a build. But yes, if your registry has a new ASDF, then your next ASDF operation may smash your session. Oops. This could be alleviate by ASDF maintaining a "earliest version I'm sufficiently compatible with that I won't smash the current state if I upgrade from it", but that requires more testing, and I haven't tried it, and not enough people care to demand that feature. If upgrading ASDF in a live image is your kind of things, though, it's definitely a feature you'll want to add. I don't believe there has been any big change requiring smashing the session since 2.27, but that's now for you to test. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org A peaceful communist? Take him to a place better run than his commune. Claims he the "extra" wealth around? not peaceful. If not, no commie.

On Thu, Nov 7, 2013 at 12:40 PM, Robert P. Goldman <rpgoldman@sift.info> wrote:

Faré wrote:

...

You don't have to rewrite your source-registry.conf for something that's temporary. Maintain your list, and tuck it into the parameter you pass to initialize-source-registry, or push stuff to the central-registry. Re-initializing the source-registry does NOT smash anything about your lisp session; all it does is update where ASDF will find the systems.

Let me make sure I understand the interaction between the different search methods.

By default, we search using asdf:*central-registry* and if we fail to find the system definition using that, we move on to use the source registry that is built using your DSL, correct?

At least that is how I interpret the setting of asdf:*system-definition-search-functions* as in my copies of SBCL and ACL.

Correct. Note that the central-registry is lazy in how it scans the filesystem, whereas the source-registry is eager. And of course, quicklisp will customize *system-definition-search-functions* to add its functionality, and so can you customize things. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Malthusianism: because growth may stop within centuries, we must use extreme violence to put an end to it now and make everyone poor today.