Public SourceMage Discussion List

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

On Fri, Sep 29, 2006 at 03:11:47PM +0200, Flavien Bridault wrote:
> Le jeudi 28 septembre 2006 à 19:20 +0200, Andraž "ruskie" Levstik a
> écrit :
> > Andrew Stitt wrote :
> > 
> > > How about libpatch? The basic idea is to provide some sort of API for
> > > spells to uniformly describe their patches. The API has to be generic
> > > enough to support both simple usages and complex ones. Patching of
> > > course, requires touching all three phases of cast (depends-resolution,
> > > downloading, building). Its non-intrusive to the core of sorcery, and
> > > can even be prototyped outside sorcery.
> > > 
> > 
> > This is a good idea acctually. It's basicaly something to be plugged
> > into sorcery and we have a spec for it as well...
> > http://wiki.sourcemage.org/libpatch
> > 
> The students have almost 100 hours to work on that project. Do you think
> the work needed on libpatch takes all this time ? Note that they would
> probably not be experienced with bash programming nor with SMGL...
> Looking at the bug, I saw that there was already some work done. What
> has been done exactly ? Can/shall we not link libpatch work with
> http://wiki.sourcemage.org/Grimoire_Patches ?

libpatch is still a fairly abstract concept. There have been attempts
at work on it, both code and spec. However, there are still issues
with creating something that is useful easily extendable and satisfies
everyones requirements. None of the work thus-far seems to fully cover
the entire problem. So a lot of the initial work will be in requirements
gathering and design. I would advise not to use the existing work as a
starting point but to look at the big picture first.

I'll try and go over some of the external requirements and technical
challenges involved. People can add to the requirements if I miss something.

Basic requirements:
Should have an api to simply specify a patch.
Should have an api that queries the user about a patch (optional patches).
Should have an api to check what patches have been enabled.
The api at minimum must have a way to specify the patch filename, and
one or more urls.
Should be possible to specify patch application ordering OR dependencies
between patches (the latter case means something will have to determine
the order, its also easier to program to).
Should be easy to wrap menus and other things around the core api (eg
over-ride the standard query mechanisms).
Should be easy to add more patches (such as through a sub-directory layout, 
see the linux and mutt spells as examples).

Technical stuff:
In terms of implementation all three phases of cast need adjusting.

First the "depends resolution" phase, "where what spells will be cast how" is
determined, needs a way to accept patches. The original proposal suggests
a PATCH file. I have mixed feelings about that because config options,
depends and patches may relate to one-another in unknown ways, which may
make it more challenging to use. Onthe other hand, the calls could just
be used in CONFIGURE, which makes it hard to disable all patching. In
anycase, somewhere in that pipeline the spell specifies its patches
through aforementioned api. That data has to get stored somewhere,
that can either be in persistent vars, or a new table, or possibly in a
temporary location during cast, and only present in the tablet after cast
(so as not to clutter up /var/state/sorcery).

After depends resolution, the download phase needs to see what patches
were requested and download them (this could happen in DOWNLOAD, or in a
new file). The easiest way for this to happen is during "spell loading"
some variables (like the SOURCEn_* vars) are populated. Similarly during
the build phase, the unpack step (PRE_BUILD) will need to access those
variables and apply the patches. It may or may not be useful to include
a new file for applying patches after PRE_BUILD but before BUILD. Some
control over how the patches are applied may be useful, for extreme stuff
the spell author would just have to diverge from the default apply patch
code as normal for other parts of cast.

Lastly, some notes on how api's are supposed to work in sorcery. Not
everything has to or should be put directly in sorcery. Sorcery needs to
stay as simple and clean as possible. So the basic building blocks may
go in sorcery, but then more complicated things are a better fit outside,
closer to those who actually use them. A big part of this is figuring
out where the boundary should go. Most of this can be prototyped just
in the grimoire using grimoire libraries, which would probably give a
more clear picture of what needs to go in sorcery.

As for them not being bash programmers, I wouldn't worry, if they
can program in any language, they can pick up bash, none of this is
exceedingly complicated coding either. Its more of a design problem.

-Andrew

-- 
_________________________________________________________________________
| 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  |
-------------------------------------------------------------------------

Attachment: pgpiirRfujUoF.pgp
Description: PGP signature