Re: New package system design draft

dv> You say this: dv> And then that: dv> ... which I don't understand. dv> 1/ Isn't this redundant ? Absolutely. It's just an efficiency thing. dv> 2/ What do you call an "Emacs incarnation" ? dv> Is it the set of (GNU or X)-Emacs, (no)Mule and other compilation-time dv> flags ? Is it a purely static thing, or does it include dynamic stuff, like dv> "there's no reason to make package Foo available in the current XEmacs dv> session, because it can only work under X and there're only tty frames dv> right now" ? The former. These will be evaluated upon startup, mainly. dv> 3/ What do you call a package hierarchy exactly ? Can you have sub-hierarchies dv> in there ? No. dv> And what if a package has several of your predicates ? Huh? It has only one. dv> Where dv> should it go ? You must decide upon installation where it goes. This has nothing to do with predicates. dv> To be more explicit, suppose package foo can't run under mule, dv> package bar can only run under mule, and package baz can do dv> both (it decides by himself). Where should they go ? This isn't prescribed by the package system, and it shouldn't be. You'd probably have a default setup with a separate mule hierarchy in which you might put bar. The rest, you'd put in an unconditionalized hierarchy. The only thing you have to watch out for is that a package hierarchy predicate must not inadvertently "hide" packages inside, i.e. you don't want to put packages which run under no-Mule in a package hierarchy conditionalized on Mule. dv> Why not \usepackage{specification} ? :-) :-) dv> What happens if there's no match for this specification ? You get an error. dv> I understand that this is probably in case several packages provide dv> the same feature at some point. We have (or had?) this already with vc vs. vc-cc, didn't we? dv> But is it possible for a package to require dv> another one ? Like, in gnus you would have (require-package w3 <spec). I don't understand this. What's "<spec)"? In Gnus, you would require specific features from within W3, just as it is currently. The feature may be called w3 as well, but so what? dv> Which brings us to another point. Suppose I have a use-package for w3 dv> and a certain spec, but gnus requires w3 with another spec. How will this be dv> solved ? This will also give an error. You can't solve this without a Lisp-level module system. dv> And a last question: what about the place of C modules in this package dv> layout ? I don't know enough about the C module system yet to make a definitive statement, but I've implemented at least two C module interfaces for Scheme engines, so I'm reasonably confident that the extension will be straightforward. Just add a directory to the package structure and extend the API. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla