exactly. what we need in the long term is a complete better integration process. I dream to have a git pharo project with submodules and pull requests. Slowly the tools are coming, but this will take time to implement. In the mean time, we need to do all the steps we can to allow us to achieve the modularisation goal. Even if they look not easy because we are still building it, or too used to previous ways of doing it. Esteban
On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
And do not forget that with better Pharo modularization it will start to be a problem on more lower level. When eg. Morphic will be an "exteranal" Pharo package.
-- Pavel
2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:
On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileandrei@gmail.com> wrote:
But this only works for releasing simple configurations that do not depend on other configurations. This would work for rubric, for example, but not for other configurations we have in gtools.
then you have two options:
1) you rewrite your configurations to not need nested configurations. This is not recommendable in huge projects like Seaside, but things like GTools are easily (I did a quick check and your 3 configurations have in total 7 packages⦠would not be a problem to have them without nesting projects and just using the packages). In fact, this is how Dale recommends using configurations (if I understood him right). 2) we enhance the tools to also allow the commit of nested packages.
I think both approaches needs to be done: you donât need unnecessary complexity in your configurations and we need to add some nesting support to commit new version.
What is not admisible, IMO, is to do something that is wrong just because it looks easier in the short term (and I say âin short termâ because what looks easier now will generate a lot of problems in the future).
cheers, Esteban