Public SourceMage Discussion List

[Andrew Stitt <afrayedknot AT thefrayedknot.armory.com>]

The last time this was discussed the problem was bisected in several
ways. One issue is that of what the grouping means. In this context it
appears to be an all or nothing semantic. If you remove foo, you must
also rebuild the relavent parents of foo without bar. Other scenarios
may be possible.

A partial resolution was suggested whereby sorcery would provide
a lower-level queryless depends function (all the depends functions
ultimately call a single function once they determine if the dependency
is enabled (if optional) and what spell its for (if a provider). That
solves the UI issue of presenting multiple queries unnecessarily to
the user. It however does not solve the grouping semantics issue at all.

Proposals 1 and 2 do not address grouping semantics issue and have
unfavorable side-effect which could be resolved using the above.

I think the larger issue here is that the problem has not been clearly
and concisely stated. Someone should cite specific examples of this
problem to ensure we're solving the right problem. I'm not sure we're
ready to move into the realm of hypotheticals. Although maybe everyone
knows abuot this problem already except me.

Theres also a growing misunderstanding about sorcery features, I am
certainly at least partially at fault for it. The goal isn't to avoid
creating new sorcery features entirely. Instead first qualify the
problem. Then identify what is difficult/impossible to do outside of
sorcery. Often times there isn't anything different/impossible to do
outside of sorcery, in which case no sorcery changes are needed.
Next figure out what aspects of the problem involve "policy". Policy
tends to include behaviors, specifically behaviors that might not work
in all situations. Those things shouldn't be in sorcery. Then figure out
what sorcery *does* need to do for you, then come up with an interface
to that, then build on top of that in the grimoire the api you want.
This is just a partial re-statement of what Seth was talking about yesterday.

In other words, its not that new sorcery features are to be avoided,
its that sorcery features at high abstraction levels (which set policies
for example) are to be avoided. Features at a sufficiently generic
abstraction level are prefered.

So far I see evidence that the problem can not easily be solved entirely
outside of sorcery. I also see evidence that some abstraction between
spells and groups of spells is needed. Proposal 3 as I understand it uses
spells for this abstraction (meta-spells which are defined as a breed of
profile spell). The counterargument I'm seeing is that spells are too
heavy of an abstraction for this, and I agree. I do agree however that
this approach would probably work, but might not be a very good way of
doing it long-term.

So, first lets quantify the problem. What spells/spell groups need this
functionality? For sub-depends what I did was create a feature bug for
it, and have spell bugs with sub-depends as the resolution depend on
it. Then I looked for the common thread between them. Start with real
examples and lets objectively analyize them.

-Andrew


On Sat, Dec 16, 2006 at 11:14:12PM +0200, Juuso Alasuutari wrote:
> I'm still in the blue about what's the best way to handle grouped optional 
> dependencies. I mean cases where one optional compile flag, if enabled, 
> will 
> require more than one dependency to be added.
> 
> Here are some ways to solve this:
> 
> 1) The oft-used approach is to config_query about the option, then do 'if 
> VAR; 
> then depends foo && depends bar'. This has the problem 
> that 'dispel --dispel-parent yes foo' will treat the parent as broken, not 
> as 
> recastable.
> 
> 2) Another solution is to do 'optional_depends foo && if is_depends_enabled 
> foo; then depends bar'. Although this causes the first dependency to get 
> marked as optional, the rest of them still suffer from the same issue as in 
> 1).
> 
> 3) Adding a meta spell (i.e. dedicated profile spell) is something that 
> would 
> actually seem to work. If the parent spell optionally depends on "meta", 
> which only pulls in foo and bar, thenall is  well. In that 
> case 'dispel --dispel-parent yes foo' will dispel meta, and that in turn 
> will 
> prompt to recast the parent spell without the optional dependency "meta".
> 
> But we don't seem to have any tradition of using "meta spells" like this. 
> The 
> profile spells out there are for pulling together big stuff like e.g. the 
> basesystem. The idea of adding a new profile spell (of the present kind) 
> for 
> a single optional dependency is certainly a bit of a turn-off.
> 
> Yet I can't help but wonder if we could indeed use "meta spells" for 
> handling 
> grouped optional dependencies. Let's say we add a section called meta in 
> the 
> grimoire. We'll make use of the soon-to-be spell file inheritance scheme 
> and 
> put dummy PRE_BUILD, BUILD, and INSTALL files in the section directory. The 
> spells could have a naming scheme that distinguishes them from the rest, 
> for 
> instance they could all begin with _. They could be more liberally disposed 
> of when the occasion arises, i.e. when they're not needed by any spells 
> anymore.
> 
> Although I can't completely wash away the taste of ad-hoc from my mouth 
> when I 
> ponder the option, I think it's at least worth a discussion, as it would 
> fit 
> in well with our present practices. I don't know if I'm alone with my 
> concern, but I do feel that we should somehow address the problem I've 
> outlined, be it through "meta spells" or some other means.
> 

-- 
_________________________________________________________________________
| Andrew D. Stitt  | acedit at armory.com    | astitt at sourcemage.org | 
| irc: afrayedknot | Sorcery Team Lead       |      ftp://t.armory.com/ |
| 1024D/D39B096C   | 76E4 728A 04EE 62B2 A09A 96D7 4D9E 239B D39B 096C  |
-------------------------------------------------------------------------