Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

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





--- Comment #15 from Andraž 'ruskie' Levstik <ruskie+bugs AT codemages.net>  
2009-09-25 12:12:47 ---
(In reply to comment #14)
> I meant the part where you don't set the term title according to spell
> success/failure.
> 
> USE_HOOKS won't fallback to "on" if the var is already set and empty.
> 

Hmm actually it should fallback to off by default. Also some of the other
settings shoulrd be removed: mailreports and sounds

> cast_spell would be better named cast_spell_start or just spell_start. ?
> 

Hmm I basically used the same naming that sorcery uses internally was less
confusing than trying to figure out where something would map.

> Most if not all of the calls that go through run_spell_file could be made 
> in it
> instead.
> 

You mean pre_HOOK and post_HOOK to be in there? Well what if something
generates some extra stuff that a user might want to be able to hook into? 
They
wouldn't be able to then.

> There is some inconsistency on when you use hooks or not - eg. BUILD always 
> has
> them, while CONFLICTS just if the file is there.
> 

Well BUILD always get's run even if it's not there. Conflicts only when it's
there.

> *_DOWNLOAD is probably not needed. It also suggest it is run before/after
> DOWNLOAD, but that is not completely true.
> 

Hmmm what if someone wants to see when the download finishes? or when it 
starts
etc. I'm hard pressed to find anything in the not needed category.

> I'm also not sure DETAILS and PRE_SUB_DEPENDS should be there, since these
> files get run multiple times per spell.
> 

Hmmm will look into this. Not sure if I tested this if it get's run only once
or not. If it does get run multiple times I'll remove it as a technical issue.

> I don't see how any hook could work, since they are in subdirs of what you 
> are
> looking at.
> 

They work... The intended use is:

hook file and in it sourcing any other necessary hooks. This makes it easy to
overlay various hooks without needing to write a ton of stuff.

Example:
cat /var/lib/sorcery/hooks/cast_final
. mail/cast_final
. cleartext/cast_final
. xtermtitle/cast_final

And so forth. This is as designed.

> libhook has some bad comments.
> 

Erm???

> libhook should be available to the hooks directly, so they don't need to 
> source
> it.

It shouldn't be. It's there to provide supporting functions that we already
have. But it is not necessary. A person can easily provide their own. So yes
once there is some effort to rewrite the current functions libhooks can
disapear other than for documentation though that can easily go into a hooks
manpage. Infact it is designed in such a way to have as little impact as
possible.

You remove /var/lib/sorcery/hooks and sorcery should still be able to run
without a problem. So yes a person can replace it all and it will still be
usable. What I need to add to run_hook is a check to see if the file is root
owned and has proper permissions. Only root should be able to edit it. Else
it's a security hole.

> It would be better to have hooks as functions (similar to run_spell_file), 
> so
> the spell/user would only need to modify one file (the libhooks) and most of
> the centuplication would be gone. The file would be read on startup and then
> the respective functions would be called as needed.

I don't agree with this. I like one file per hook as it makes them much more
easy to mess with and it avoids for the user to actually know a lot about 
bash.
Not to mention this makes it easy to disable random parts easily... i.e. don't
want a post_BUILD hook -> remove the file gone.

We won't agree on a single file per hook vs function per hook approach.
Different mindset. I prefer everything as a file you seem not to.


I put a lot of thought into how it should be organized. I will take comments
into account but this is simply how I see it working and how I'm willing to
implement them. It is something I wish to see included but I won't redesign it
without a hell of a good reason.

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