[asdf-devel] :exclude in source-registry.conf getting ignored.
Hi list, Is it intended that :exclude in ~/.config/common-lisp/source-registry.conf should come before the :tree directive(s)[1]? To me, the manual seems to specify that the order in which the directives are provided does not matter. I'm using asdf version "1.720". To set the context, and perhaps as another question, I was originally investigating if it was possible to exclude a specific tree (sure, matching a pattern works and is good enough) or directory, or have some other way to suppress the loading of duplicated systems (usually repo branches). Yong. [1] Compare: With this in the user config file, (:source-registry (:exclude "asdf-exclude") (:tree "/home/tyc20/lisp/") :ignore-inherited-configuration)
(flatten-source-registry) ==>((#P"/home/tyc20/lisp/imp/sbcl-1.0.29-x86-linux/install/lib/sbcl/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")) (#P"/home/tyc20/lisp/" :RECURSE T :EXCLUDE ("asdf-exclude")))
With this in the config file instead: (:source-registry (:tree "/home/tyc20/lisp/") (:exclude "asdf-exclude") :ignore-inherited-configuration)
(flatten-source-registry) ==>((#P"/home/tyc20/lisp/imp/sbcl-1.0.29-x86-linux/install/lib/sbcl/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")) (#P"/home/tyc20/lisp/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")))
Yes, I agree the exclude API is not very clean, sorry about that. If you have a better design to propose, I'm all ears. Otherwise, I'll just document better what we have. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Language is froth on the surface of thought. — John McCarthy On 11 May 2010 04:37, szergling <senatorzergling@gmail.com> wrote:
Hi list,
Is it intended that :exclude in
~/.config/common-lisp/source-registry.conf
should come before the :tree directive(s)[1]?
To me, the manual seems to specify that the order in which the directives are provided does not matter.
I'm using asdf version "1.720". To set the context, and perhaps as another question, I was originally investigating if it was possible to exclude a specific tree (sure, matching a pattern works and is good enough) or directory, or have some other way to suppress the loading of duplicated systems (usually repo branches).
Yong.
[1] Compare:
With this in the user config file,
(:source-registry (:exclude "asdf-exclude") (:tree "/home/tyc20/lisp/") :ignore-inherited-configuration)
(flatten-source-registry) ==>((#P"/home/tyc20/lisp/imp/sbcl-1.0.29-x86-linux/install/lib/sbcl/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")) (#P"/home/tyc20/lisp/" :RECURSE T :EXCLUDE ("asdf-exclude")))
With this in the config file instead:
(:source-registry (:tree "/home/tyc20/lisp/") (:exclude "asdf-exclude") :ignore-inherited-configuration)
(flatten-source-registry) ==>((#P"/home/tyc20/lisp/imp/sbcl-1.0.29-x86-linux/install/lib/sbcl/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")) (#P"/home/tyc20/lisp/" :RECURSE T :EXCLUDE (".bzr" ".cdv" "~.dep" "~.dot" "~.nib" "~.plst" ".git" ".hg" ".pc" ".svn" "CVS" "RCS" "SCCS" "_darcs" "_sgbak" "autom4te.cache" "cover_db" "_build")))
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On 5/12/10, Faré <fahree@gmail.com> wrote:
Yes, I agree the exclude API is not very clean, sorry about that. If you have a better design to propose, I'm all ears.
<<snip>> I would if I could. :) While my original thoughts on this appear simple at first, on further examination, I have become confused with a couple of issues. Some suggestions and questions: 1. I think most hackers would expect that *default-exclusions* should not be overridden if the user provides an :exclude directive. (setf *default-exclusions* rest) should be something like (appendf *default-exclusions* rest) 2. What does it mean to inherit a configuration? Will exclusions be shared? For example, suppose directory "/a/b/x/" is meant to be excluded, and is specified in the user config file (which :inherit-configuration). If the system config (being inherited, if I understand correctly) specifies the tree "/a/b/", x/ (being a subdirectory) will get re-included again. 3. At the risk of confusing the meaning of "inherit" with CLOS inheritance, I was going to propose solving the "order of directive specification" issue by pre-reading all config info into a first class configuration object. This may facilitate inspecting/reasoning over them as well as supporting more direct interactions between directives. Thanks all I can think of for now... Yong.
On 11 May 2010 04:37, szergling <senatorzergling@gmail.com> wrote:
Hi list,
Is it intended that :exclude in
~/.config/common-lisp/source-registry.conf
should come before the :tree directive(s)[1]?
To me, the manual seems to specify that the order in which the directives are provided does not matter.
<<snip>>
Honorable Senator, I hopefully fixed your issue in 1.723, and another issue in 1.724. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Procrastination is great. It gives me a lot more time to do things that I'm never going to do. On 14 May 2010 05:06, szergling <senatorzergling@gmail.com> wrote:
On 5/12/10, Faré <fahree@gmail.com> wrote:
Yes, I agree the exclude API is not very clean, sorry about that. If you have a better design to propose, I'm all ears.
<<snip>>
I would if I could. :) While my original thoughts on this appear simple at first, on further examination, I have become confused with a couple of issues. Some suggestions and questions:
1. I think most hackers would expect that *default-exclusions* should not be overridden if the user provides an :exclude directive.
(setf *default-exclusions* rest)
should be something like
(appendf *default-exclusions* rest)
2. What does it mean to inherit a configuration? Will exclusions be shared? For example, suppose directory "/a/b/x/" is meant to be excluded, and is specified in the user config file (which :inherit-configuration). If the system config (being inherited, if I understand correctly) specifies the tree "/a/b/", x/ (being a subdirectory) will get re-included again.
3. At the risk of confusing the meaning of "inherit" with CLOS inheritance, I was going to propose solving the "order of directive specification" issue by pre-reading all config info into a first class configuration object. This may facilitate inspecting/reasoning over them as well as supporting more direct interactions between directives.
Thanks all I can think of for now...
Yong.
On 11 May 2010 04:37, szergling <senatorzergling@gmail.com> wrote:
Hi list,
Is it intended that :exclude in
~/.config/common-lisp/source-registry.conf
should come before the :tree directive(s)[1]?
To me, the manual seems to specify that the order in which the directives are provided does not matter.
<<snip>>
On 5/16/10, Faré <fahree@gmail.com> wrote:
Honorable Senator,
Ugh, I really need to switch from this email account. Just "Hi Yong" or whatever please. I'm now stuck with an email with a frivolous and uninformative name.
I hopefully fixed your issue in 1.723, and another issue in 1.724.
Yes, I think :also-exclude is a nicer way of doing it. Thanks! Yong.
participants (3)
-
Faré -
szergling -
Theam Yong Chew