[asdf-devel] Optional dependencies
Quite a few libraries come with reader hacks. They usually come with a ENABLE-FOO-SYNTAX function. I'd like those libraries to optionally depend on the named-readtables library, and define a named readtable that includes their hacks. So users can just use (IN-READTABLE FOO:SYNTAX) on a per-file basis. What do you think would be the best way to do it? There's :weakly-depends-on which only loads a dependency if that system is present. Named-readtables pushes :NAMED-READTABLE to *FEATURES*. So in principle, people can use (:weakly-depends-on :named-readtables) and then #+named-readtables (named-readtables:defreadtable ...) Or put that definition in a file readtable.lisp and use feature-conditionalized compilation in the system definition (which used to be, and I guess still is, awfully awkward -- I never remember how to do it.) Now I'm wondering how good that solution is. What is if the library was compiled with a core that happened to include named-readtables? Trying to load that fasl with another core file would probably result in an obscure error. Now, it's a shoot-yourself-in-the-foot kind of thing to do, but I'd think it's something that can happen quite easily. Does ASDF somehow guard against this case?
From what I can see, it appears that :WEAKLY-DEPENDS-ON was added in a quick rush thinking that it might be appropriate for conditional compilation, but it really is not. Does that seem true to you, too?
Maybe people can share how they got bitten by it? I'd think ASDF should include a ./configure step (there are extension for that kind of thing out there), and should then save configuration choices persistently, and check for these when loading a system. -T. PS. Thanks, appreciation, and kudos again to Fare and Robert for having taken up the ASDF hat.
On Thu, Aug 19, 2010 at 10:13 AM, Tobias C Rittweiler <tcr@freebits.de>wrote:
Now I'm wondering how good that solution is.
Bad. I already spoke about why I am against reader conditionalization in ASDF files. Dependencies should only be either features (strictly CL implementation dependent not the ones introduced by libraries) or modules (thus recognized by ASDF), which may themselves be optional or compulsory and ASDF should provide a good syntax for both.
What is if the library was compiled with a core that happened to include named-readtables? Trying to load that fasl with another core file would probably result in an obscure error. Now, it's a shoot-yourself-in-the-foot kind of thing to do, but I'd think it's something that can happen quite easily. Does ASDF somehow guard against this case?
This is one of the reasons why reader conditionalization is bad: the dependency is stored outside ASDF, in *features*, which is not good. If one sticks to ASDF, it would recognize the named-readtables modules to be present in the core and thus it would work, or it would not find it and then it would load it.
From what I can see, it appears that :WEAKLY-DEPENDS-ON was added in a quick rush thinking that it might be appropriate for conditional compilation, but it really is not. Does that seem true to you, too?
I once tried to understand how :weakly-depends-on works, but I simply could not (ASDF internals really elude me). Hence, I am not sure whether it is the replacement I have in mind, but the name seems ok :-) Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
In article <AANLkTimQqsEthHPUgC7cda1Wz_3Q4UuXZ5NEQpKDB2Ds@mail.gmail.com>, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:
On Thu, Aug 19, 2010 at 10:13 AM, Tobias C Rittweiler <tcr@freebits.de>wrote:
Now I'm wondering how good that solution is.
Bad. I already spoke about why I am against reader conditionalization in ASDF files. Dependencies should only be either features (strictly CL implementation dependent not the ones introduced by libraries) or modules (thus recognized by ASDF), which may themselves be optional or compulsory and ASDF should provide a good syntax for both.
The parts you left out did not talk about reader conditionalization in ASD(F) files. So I'm confused by what you mean exactly. The library author somehow has to arrange for condition compilation. ASDF could make per-file conditionalization easier, but sometimes you want per-toplevel-form conditionalization. That's what #+,#- provide which work on *FEATURES*. I don't see a way around that other than ASDF providing an analogous reader macro around FIND-SYSTEM.
What is if the library was compiled with a core that happened to include named-readtables? Trying to load that fasl with another core file would probably result in an obscure error. Now, it's a shoot-yourself-in-the-foot kind of thing to do, but I'd think it's something that can happen quite easily. Does ASDF somehow guard against this case?
This is one of the reasons why reader conditionalization is bad: the dependency is stored outside ASDF, in *features*, which is not good. If one sticks to ASDF, it would recognize the named-readtables modules to be present in the core and thus it would work, or it would not find it and then it would load it.
Indeed that was my point. Try to load it, if that does not succeed, it should barf an error. -T.
On Fri, Aug 20, 2010 at 1:07 PM, Tobias C Rittweiler <tcr@freebits.de>wrote:
The parts you left out did not talk about reader conditionalization in ASD(F) files. So I'm confused by what you mean exactly.
Sorry, I understood the reader macros were intended to appear in the ASDF itself. I obviously misread your email, but I needed a third reading to grasp it all -- please tell me whether the following description is right :-) Goal: Library B has some facilities that make sense when library A is present. The goal is to make these facilities compiled and loaded whenever possible. Solutions offered: 1) Let the library B :weakly-depends-on A and use the fact that library A introduces a new feature. The code in library B is then populated with #+/#- depending on that feature. 2) One of the components in the system definition includes all the code that depends on A and is loaded only when that :feature is active 3) One of the components in the system definition isolates all dependency on A and this component :weakly-depends-on 4) Make two separate system definitions, one with and one without code for A I believe 1 and 2 have problems because as you say the feature might be present in the core. #3 is better because the code that depends on A is only loaded when ASDF knows that A is present and loadable -- no dependency on non-standard features. Method #3, if working (which Fare seems not to be sure about) is also the substitute for reader macros in ASDF files. Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com
In article <AANLkTi=LvcyS_BnUYgNafFoTSbsOv857hzpjQhomAP6h@mail.gmail.com>, Juan Jose Garcia-Ripoll <juanjose.garciaripoll@googlemail.com> wrote:
On Fri, Aug 20, 2010 at 1:07 PM, Tobias C Rittweiler <tcr@freebits.de>wrote:
The parts you left out did not talk about reader conditionalization in ASD(F) files. So I'm confused by what you mean exactly.
Sorry, I understood the reader macros were intended to appear in the ASDF itself. I obviously misread your email, but I needed a third reading to grasp it all -- please tell me whether the following description is right :-)
Goal: Library B has some facilities that make sense when library A is present. The goal is to make these facilities compiled and loaded whenever possible.
Solutions offered:
1) Let the library B :weakly-depends-on A and use the fact that library A introduces a new feature. The code in library B is then populated with #+/#- depending on that feature.
2) One of the components in the system definition includes all the code that depends on A and is loaded only when that :feature is active
3) One of the components in the system definition isolates all dependency on A and this component :weakly-depends-on
4) Make two separate system definitions, one with and one without code for A
Yes that seems to be it. Thanks for the summary. However, I don't understand how #2 is supposed to achieve the goal. In #2, the A-dependent code is loaded if :A is in *FEATURES*, right? But that only works if A happened to be loaded before. So there must be some kind of :WEAKLY-DEPENDS-ON be involved, too, in which case #2 becomes mostly a variation of #1.
I believe 1 and 2 have problems because as you say the feature might be present in the core. #3 is better because the code that depends on A is only loaded when ASDF knows that A is present and loadable -- no dependency on non-standard features. Method #3, if working (which Fare seems not to be sure about) is also the substitute for reader macros in ASDF files.
I agree #3 sounds like a step forward. At least in the ASDF currently shipped with SBCL, there's a bug in the code that handles weakly-depends-on. See patch attached. Despite the patch I couldn't really test the issue, and got annoyed by ASDF recompiling SBCL contribs on :FORCE T which will result in failure. Reminded me that I'm supposed to do something else. -T. Index: contrib/asdf/asdf.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/contrib/asdf/asdf.lisp,v retrieving revision 1.32 diff -u -r1.32 asdf.lisp --- contrib/asdf/asdf.lisp 26 Jun 2010 05:03:58 -0000 1.32 +++ contrib/asdf/asdf.lisp 21 Aug 2010 08:05:43 -0000 @@ -2221,7 +2221,7 @@ (or (find-component parent name) (make-instance (class-for-type parent type))))) (when weakly-depends-on - (appendf depends-on (remove-if (complement #'find-system) weakly-depends-on))) + (appendf depends-on (remove-if (complement #'(lambda (s) (find-system s nil))) weakly-depends-on))) (when *serial-depends-on* (push *serial-depends-on* depends-on)) (apply #'reinitialize-instance ret
Dear Tobias, I personally think this "weakly-depends-on" is a horrible mess. If you want FOO, require FOO. If you want FOO+READTABLE, require FOO+READTABLE. And so have two systems FOO and FOO+READTABLE. I think that's what the dwim.hu guys now do. It also works better with XCVB, this way.
I'd think ASDF should include a ./configure step (there are extension for that kind of thing out there), and should then save configuration choices persistently, and check for these when loading a system.
I think this can be external to ASDF itself. At ITA, we have scripts that do things like that. My, it's ugly. Trying to get rid of it. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Mathematics is the Queen of Science but she isn't very Pure; she keeps having babies by handsome young upstarts and various frog princes. — Donald Kingsbury (In "psychohistorical crisis", 2001)
Is this one of those cases where you have to do some kind of oddball dependency failure trapping? I have always disliked the fact that ASDF makes you implement conditionals as error-handlers. It seems like there should be a nicer syntax for conditionals in system definitions.... Sorry, I'm on vacation, so I don't have such good access to examples right now. best, r
In article <AANLkTi=QXv-2MeF5jqi=oZHk4w5zjhr=vLp+qAEKKcwg@mail.gmail.com>, Faré <fahree@gmail.com> wrote:
Dear Tobias,
I personally think this "weakly-depends-on" is a horrible mess.
If you want FOO, require FOO. If you want FOO+READTABLE, require FOO+READTABLE.
And so have two systems FOO and FOO+READTABLE. I think that's what the dwim.hu guys now do. It also works better with XCVB, this way.
I'll follow up to this suggestion on Juanjo's summary mail.
I'd think ASDF should include a ./configure step (there are extension for that kind of thing out there), and should then save configuration choices persistently, and check for these when loading a system.
I think this can be external to ASDF itself. At ITA, we have scripts that do things like that. My, it's ugly. Trying to get rid of it.
How can this be external? It must be integrated into the way ASDF stores fasls, and loads system. Now it may be that its GF architecture is extensible enough but then GF extensions are hard to get to a point where they compose. -T.
Hi Tobias, One thing, that you might want to use instead of :weakly-depends-on is feature dependencies. The syntax is (:feature <feature>) in dependency list, like this: (defsystem #:test :depends-on (#:cl-ppcre (:feature :custom-readtables)) Although, I didn't try it in modules, but I guess, it should work there as well, since the mechanism is generic. Proceed at your own risk... ;) Best, Vsevolod On Thu, Aug 19, 2010 at 11:13 AM, Tobias C Rittweiler <tcr@freebits.de>wrote:
Quite a few libraries come with reader hacks. They usually come with a ENABLE-FOO-SYNTAX function. I'd like those libraries to optionally depend on the named-readtables library, and define a named readtable that includes their hacks. So users can just use (IN-READTABLE FOO:SYNTAX) on a per-file basis.
What do you think would be the best way to do it?
There's :weakly-depends-on which only loads a dependency if that system is present. Named-readtables pushes :NAMED-READTABLE to *FEATURES*. So in principle, people can use
(:weakly-depends-on :named-readtables)
and then
#+named-readtables (named-readtables:defreadtable ...)
Or put that definition in a file readtable.lisp and use feature-conditionalized compilation in the system definition (which used to be, and I guess still is, awfully awkward -- I never remember how to do it.)
Now I'm wondering how good that solution is.
What is if the library was compiled with a core that happened to include named-readtables? Trying to load that fasl with another core file would probably result in an obscure error. Now, it's a shoot-yourself-in-the-foot kind of thing to do, but I'd think it's something that can happen quite easily. Does ASDF somehow guard against this case?
From what I can see, it appears that :WEAKLY-DEPENDS-ON was added in a quick rush thinking that it might be appropriate for conditional compilation, but it really is not. Does that seem true to you, too?
Maybe people can share how they got bitten by it?
I'd think ASDF should include a ./configure step (there are extension for that kind of thing out there), and should then save configuration choices persistently, and check for these when loading a system.
-T.
PS.
Thanks, appreciation, and kudos again to Fare and Robert for having taken up the ASDF hat.
_______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
participants (5)
-
Faré -
Juan Jose Garcia-Ripoll -
Robert Goldman -
Tobias C Rittweiler -
Vsevolod Dyomkin