Public SourceMage Discussion List

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

On Thu, Nov 16, 2006 at 01:07:34PM -0600, Jeremy Blosser wrote:
> On Nov 16, Andrew Stitt [afrayedknot AT thefrayedknot.armory.com] wrote:
> > I propose that we move the installation extras (the pre-stage-root
> > POST_INSTALL) to a new file that runs between INSTALL and
> > POST_INSTALL. Then change the definition of POST_INSTALL such that
> > it is where a spell can have direct access to the stage prior to its
> > installation. I can go one step further and suggest that the default
> > POST_INSTALL is sorcery's staged installation code. So, a spell
> > could override that if it wanted to. If stage-root was disabled then
> > either POST_INSTALL wouldn't get run, or the default would be a no-op.
> 
> Making the meaning of POST_INSTALL for spellwriters be "things to do
> *prior* to installation" seems counterintuitive.  I know we are dealing
> with two meanings of "install" (one for the install into the stage, one for
> the install to the live system), but just read that sentence above
> "POST_INSTALL ... is where a spell ... prior to its installation" and
> hopefully it's clear that may be confusing for people.

Yea, we need another term. I propose "transfer" for sorcery's staged
installation.

> 
> I'll also note that if we made POST_INSTALL default to the staged
> installation code then for people to get the benefit of being able to
> modify the stage before the staged installation they'd need to do:
> 
> ====================
> some code1 &&
> some code2 &&
> some code3 &&
> 
> default_post_install
> ====================
> 
> which is backwards from how all the other default_ stuff usually works,
> isn't it?

Yea, its a question of api level. I could go two ways on this. Some
types of spell files do typically always call the default. On the other
hand, we may wish to further dileneate between modifying the stage, and
transfering it. In the former case the api is fairly simple, theres no
forced ordering of steps. In the latter the api is more complex, also
sorcery has defined a specific pattern, and is allowed to separate the
steps any way it choses (so long as it provides the right environment).

I think in the end I decide on the latter case. As I think thats been
the problem with POST_INSTALL all along. Its always done too many things
and never quite "fit" into the pipeline like the other files did.


> 
> I know this is pedantry, just trying to avoid future scenarios of people
> writing broken spells, I know how fond you are of those.  :-)

I do appreciate the feedback.

> 
> The first issue could be resolved changing the name of the file to
> STAGED_INSTALL instead of POST_INSTALL.  This would make it clear(er) what
> this step does, assuming you apply the default as you suggested.  It
> doesn't resolve the second issue, but maybe with that name it's more
> obvious to people that anything they want to do ahead of the STAGED_INSTALL
> can go in that file ahead of the default call.  The other way to fix the
> second issue is probably yet another spell file and I imagine we want to
> avoid that.

I dont like STAGED_INSTALL becase it comes after POST_INSTALL. That may
seem unintuitive to someone unfamilar with staging.

> 
> Or maybe we do:
> 
> ... -> INSTALL -> INSTALL_EXTRAS -> POST_INSTALL -> STAGED_INSTALL -> FINAL
> 
> since POST_INSTALL does exist already.  This would let people make their
> changes in POST_INSTALL and they'd have the option to override the staged
> install but obviously usually wouldn't need to know that was even there.
> 

Assuming we go with the split file approach, I would replace
STAGED_INSTALL with TRANSFER.

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