Thread Previous • Date Previous • Date Next • Thread Next |
Le 10/08/2012 09:50, tony byrne a écrit :
Right, (I still think that it's easier to bzr revert during development, but that will be up to people developing hooks ;))Hi Didier Alistair pointed out that I could escape from the tedium of quickly create - test - delete project by developing the hook as post_save so solves that difficulty. I had assumed that quickly would supply parameters to post_create so I could not depend on being able to run it standalone.
Btw, another question: what parameters does the hook should have (for the pre_ and post_ ones). I think that the obvious goal is to run them in the same context than the command itself: meaning, apart from commands out of tree where we use the cwd, always at the root directory of the project.
Should they just be scripts that we launch? Should they have special parameters attach?Should we just pass all optional command lines arguments that are passed to the command itself?
Another use case for a command that can affect any template is say gsettings. Imagine a command adding a array of strings (as) like quickly add gsettings as <arrayname> that could apply to all template types. It could be handled as a fundamental command quickly gsettings as <arrayname> and import gsettings into every template but that seems inelegant.
It can be seen as inelegant, but at least, it's tested and compatible. Like, what could happen if someone using the Qt template will try to add gsettings which dep on a glib mainloop? :) For the "add" command, I see that store/ being inheritable as for the boiler plate itself (and most of "good parts" should go back to the main template anyway)).
Inheriting and tweaking a command with the model I gave in another thread should just a couple of lines, I think we should focus on how to develop and experiment on this good practice with the Reboot to help people and don't duplicate code as much as possible.
Didier
Thread Previous • Date Previous • Date Next • Thread Next |