Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

http://bugs.sourcemage.org/show_bug.cgi?id=13938





--- Comment #17 from Andraž 'ruskie' Levstik <ruskie+bugs AT codemages.net>  
2009-09-27 13:13:13 ---
(In reply to comment #16)
> 1. Those two settings should stay, so you're not forced to use whatever the
> code decides.
> 

Erm? But they have no effect now.

> 2. Think of the user. How likely is she to know that that call happens in an
> equally named function for each building spell instead of at the start of 
> cast
> (global).
> 

True as this is meant for someone with no bash skills I should probably name
them better.

> 3. If you mean you want to expose more internals in no solidly defined 
> manner,
> then I say you need to put most of the calls in the functions even more.
> 

Hooks should allow people to get various bits and pieces out of sorcery but
should not be required to follow any soldily defined thing. If a hook relies 
on
a variable it does so completly on it's own. Sorcery should completly NOT care
what hooks do.

> 4. It is inconsistent. In this case the inlining would fix it, but I think I
> saw some others too.
> 

I was actually thinking adding them to run_spell_file could work but I think 
it
would possibly cause duplication since you need to account for both endings...
success and failure for a post_hook.

It should generally be run in either case since someone might want to be
notified if something fails or something succedes.

> 5. They don't need all four hooks for that.
> 

True. One before start and one after end would be enough.

> 8. Corrupted? Missing?
> 

Not all require comments. It's not hard to figure out what a pre_BUILD hook
does or a post_BUILD only the special non spell states that really need them.
I'll review them but most of that will have to go to a manpage anyway.

> 9. It is more effort if you have to source the file each time, not less. And
> you yourself claim the lib is not important, so where's the problem (except 
> for
> the overridability)?
> 

Hmm true. It's just that I don't consider those functions should be part of
sorcery in general. Feature creep and so on.

> ad) Stuff should not install in the sorcery dir. If you want the user to be
> able to edit something, it should be done in the config dir.
> 

I'm perfectly happy to put hooks into /etc/sorcery/local/hooks


> 10. With functions the user would not need to know any more bash than usual.
> The default hook lib would define just the used hooks and the others are
> documented, so it is a quick copy/paste job to add a new hook. Removing is 
> no
> harder nor simpler.
> 

copy-paste == doing this multiple times for each thing adding also becomes
harder to provide third party hooks. Example:

User has: $HOOKS_DIR/success file with the following contents:
. */success

But only some empty file in the example/success dir.

Then they:
cast hooks-dzen2
-> installs $HOOKS_DIR/dzen2/success
-> works automatically no need for the user to edit/copy-paste/etc... 
anything.
hooks-mail1
-> installs $HOOKS_DIR/mail1/success
-> works automatically no need for the user to edit/copy-paste/etc... 
anything.
hooks-xterm1
-> installs $HOOKS_DIR/xterm1/success
-> works automatically no need for the user to edit/copy-paste/etc... 
anything.

With your solution user casts hooks-dzen2,
needs to edit a file and manualy copy-paste each and every hook into the
functions he wants to use.
Repeat for every one after that.

Automating this leads to unnecessary complexity.

> ad)An elegant approach has better chances of being accepted. The current 
> method
> does not meet that criterion, there just too many redundant files.
> 

Elegenace and beauty etc... are all in the eye of the beholder. I won't 
discuss
this. If you don't like it as it is not my loss. If I write it I do it my own
way which I consider the best. I think a lot before writting code. Throw away 
a
lot of ideas before putting them anywhere. I considered functions and 
discarded
them due to the reasons written up there.

> -1. Which of these hooks do you actually use and for what?

Primarily:
cast_final
To get a summary through dzen2 or email

post_FAILURE
To get the compile log through dzen2 or email

post_SUCCESS
To get the install log through dzen2 or email

Others I have on the backburner:
post_INSTALL: to run signelf on each binary to gpg sign them.

And that's just what I can come up with. Someone might want to use alter on
them or move the entire alter functionality to hooks and always have it
automatically do that on each cast.

Someone might want to run a cleanse or remove the downloaded files after a
succesfull cast.

There's so many ideas that people can come up with that I can't even think
about.

-- 
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.