Optional components?
Robin Lee Powell
Back to poking at weblocks-dev and mudballs again.
How do people suggest I handle optional components? In this case,
weblocks comes with several storage back ends (CLSQL, elephant,
prevelance, etc), and the user may not have all of the requirements
for all of them (I myself don't have any of the elephant
requirements, for example).
How should I handle this in mudballs terms? I can't just do
weblocks-[foo].mbd, because a user might want any combination of
zero or more of them.
Thanks.
-Robin
--
They say: "The first AIs will be built by the military as weapons."
And I'm thinking: "Does it even occur to you to try for something
other than the default outcome?" See http://shrunklink.com/cdiz
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/
Sean Ross
On 22 Apr 2009, at 04:29, Robin Lee Powell wrote:
>
>
> Back to poking at weblocks-dev and mudballs again.
>
> How do people suggest I handle optional components? In this case,
> weblocks comes with several storage back ends (CLSQL, elephant,
> prevelance, etc), and the user may not have all of the requirements
> for all of them (I myself don't have any of the elephant
> requirements, for example).
Indeed, how do you currently handle this with ASDF as I would expect a
similar approach to be, if not pretty, at least functional?
One approach is to combine the subsystem syntax with lazy modules to
provide a component in weblocks which will only be loaded
when explicitly specified. This was added to provide support for the
various CLSQL backends so a similar approach could be useful.
eg.
(in-package :sysdef-user)
(define-system (:weblocks :elephant-storage) (lazy-module)
(:components "storage"))
This creates a module named elephant-storage and places it as the last
component on weblocks. Additionally this component won't be loaded
when (mb:load :weblocks) is executed but will have to be loaded
explicitly when a particular storage mechanism is required.
There is a misfeature/bug present, in that dependencies will be looked
for in the parent system and not in the global namespace which
rules out being able to specify (:needs :elephant) in the subsystem
specification so you will, unfortunately have to manually load
elephant from within
a (eval-when ...) block in one of the source files, I have raised a
bug for this (http://redmine.mudballs.com/issues/show/152) and will
bump up it's priority.
Of course this may or may not be what you are looking for....
>
> How should I handle this in mudballs terms? I can't just do
> weblocks-[foo].mbd, because a user might want any combination of
> zero or more of them.
>
I don't think I understand what you are referring to here as creating
and loading an arbitrary number of :weblocks-[foo] systems which
depends on :weblocks in Mudballs shouldn't be any more restrictive
than doing this in ASDF.
sean.
Leslie P. Polzer
> Indeed, how do you currently handle this with ASDF as I would expect a
> similar approach to be, if not pretty, at least functional?
In Weblocks this problem is "solved" by having a base system
and separate add-on systems.
Another possibility is ASDF-SYSTEM-CONNECTIONS which allows
to load components of a system only when another system is
available.
Sean Ross
This approach is also possible in mudballs using conduit-system's via
the define-conduit-system macro
or by specifying conduit-system as your systems parent class. This
will ensure that this system is autoloaded
when all of the systems dependencies are loaded. But
At this point the question I would like to answer is how would 'You'
like to be able to specify this requirement?
How would you like to specify these dependencies and how/where would
you load these extra modules.
I would lean towards lazily loaded subsystems but I'm open to
suggestions.
A bit of history first, I wrote the lazy subsystem code for clsql so
that all the various database backends making up clsql
would be encapsulated in a single system whose components could then
be loaded when needed. This was primarily
to keep the system list relatively noise free (which is also why I'm
against create <foo>-test systems) which may not
be what you want.
sean.
Leslie P. Polzer
> At this point the question I would like to answer is how would 'You'
> like to be able to specify this requirement?
>
> How would you like to specify these dependencies
Something like an :optional-dependency clause would be nice that
would only load the parts belonging to it if the dependency is
there.
The user should also be able to explicitly start loading this
optional part and then be prompted to install the optional deps.
A question that I have found to easily yield good answers sometimes
(more on this later) and that might also apply here:
How does CPAN do it?
> and how/where would you load these extra modules.
I'm not sure I understand this question -- what are the options?
> I would lean towards lazily loaded subsystems but I'm open to
> suggestions.
To what point would loading them be deferred then?
Leslie
Sean Ross
On 23 Apr 2009, at 10:53, Leslie P. Polzer wrote:
>
>
>> At this point the question I would like to answer is how would 'You'
>> like to be able to specify this requirement?
>>
>> How would you like to specify these dependencies
>
> Something like an :optional-dependency clause would be nice that
> would only load the parts belonging to it if the dependency is
> there.
>
That sounds reasonable.
> The user should also be able to explicitly start loading this
> optional part and then be prompted to install the optional deps.
>
You lost me here, which optional part would the user load?
A partial system definition would help.
> A question that I have found to easily yield good answers sometimes
> (more on this later) and that might also apply here:
>
> How does CPAN do it?
>
Agreed, there is a lot of useful precedents set by CPAN, rubygems and
co.
>
>> and how/where would you load these extra modules.
>
> I'm not sure I understand this question -- what are the options?
>
>> I would lean towards lazily loaded subsystems but I'm open to
>> suggestions.
>
> To what point would loading them be deferred then?
>
> Leslie
I see that we're approaching this problem from different directions
but here is how I pictured this working, using CLSQL as an example.
CLSQL is (or at least will be) made up of the core CLSQL system and
then N number of sql backends packaged in lazy modules.
These modules need to be loaded when a database connection is made. As
an example
when (clsql:connection *my-db-spec* :database-type :mysql) is executed
there is code which resolves the database-type to
a module in the clsql system and loads it [1].
This is what I mean by there where/when question.
The where in this case is the code which resolves the database type to
a module to load and the when is at database connection time.
sean.
1] This is just a variation of how it is currently done in the stock
standard CLSQL distribution using ASDF, where there are n systems
named clsql-[db]
which are loaded at database connection time .