quickly-talk team mailing list archive

[tony byrne <tony.badwolf@xxxxxxxxx>]

Hi Didier
 I agree bzr revert is good but the point is how to call
post_create.py. Having it as a simple script, like the store files,
covers most cases. The post_create.py script, just like the store
scripts, could  optionally import parts of quickly and discover
template or project properties. However calling it, without quickly's
help, could be ~/config/quickly/ubuntu-application/hooks/post_create.py
How about quickly hook post_create where hook discovers the template
from the project?

A cross template command, e.g. optionally adding persistence, seems to
fit naturally as

quickly create <any gnome template> <project name>
cd <project name>
quickly add -t gsettings as <array name>

but the alternative

quickly create  <any gnome template> <project name>
cd <project name>
quickly gsettings as <array name>

requires a new command which has been resisted in the past. There is
also the case where a programmer might want to add gsettings to a
flash game.

 Alistair seems to want a command something like

quickly create <any template> <project name>
cd <project name>
quickly add -t vcs git (this script also removes bzr etc)
quickly add -t vcs githost (this script also removes submitubuntu command etc)

(This is a version of his 2 templates proposal.)

The argument against -t (misuse) seems counter to open source or
liberty itself. An analogy:

Some programmers are incompetent
some citizens get drunk
prevent all programmers adding a cross template module (e.g gnome
module to a qt project)
government bans alcohol
competent programmers lose a useful tool
Didier cannot have a glass of wine with his meal.



On 10/08/2012, Didier Roche <didrocks@xxxxxxxxxx> wrote:
> Le 10/08/2012 09:50, tony byrne a écrit :
>> 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.
> Right, (I still think that it's easier to bzr revert during development,
> but that will be up to people developing hooks ;))
>
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~quickly-talk
> Post to     : quickly-talk@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~quickly-talk
> More help   : https://help.launchpad.net/ListHelp
>