Code review comment for lp:~sebastiken/anybox.recipe.openerp/group_standalone_addons

Georges, thanks, I've just installed zc.buildout with pip and tests started to run. So, I will write a test for this new option. If I make the test and commit it to my branch, Have I to do a new merge request? I usually used github's pull requests which subsequents commits are grouped and discussed in the same pull request.
About your question, if you change the value of a 'group' option on a repo, this will not be a problem, because a new directory is created and append to addons_paths. The only thing this code doesn't do is to delete old repo addon (if it exists in an another group) and it will lead to a problem because of a duplicated addon. But it seems to be imposible to check this, only checking the existance of the addon in all folders and it so impractical. I think will be simpler if user cleans all before change group value.
The second question is not contemplated. I don't check if it is an standalone addon or if stops being standalone. So I see a new problem, if user puts 'group' option to addons that are not standalone, I really don't know what happens, I suppose there will nested in three level, i.e., group_folder/addons_folder/ <-- here will be the addons. It is also a problem because OpenERP will not find those. I think it is simple to solve, maybe adding again "some magic" to know if it is standalone or not detecting __openerp__.py or __terp__.py. But I understand you complain about that in bug description above.
Tell me what you think about these problems. I am going to write the test, ignoring this troubles for now.

> Sebastian, yes you'll need to install zc.buildout, but it's more that enough
> to install it in your virtualenv.
>
> Normally, the 'develop' command as explained in this paragraph:
> http://docs.anybox.fr/anybox.recipe.openerp/trunk/contributing.html
> #development-setup
> should take care of all the dependencies.
>
> By the way, I don't care much if that's not the solution I proposed a while
> ago. This concept of 'group' seems to solve the 'standalone' use-case while
> being more general.
>
> Also, we should think of how buildout configuration evolves. For instance,
> what if one such addon changes group ? If the repo stops being a standalone
> one (such things can happen, and be outside the control of the person
> maintaining that configuration, if the answer is to start with a new target
> directory, we should say so in doc).
>
> Don't worry, these can be taken care of in later improvements.