smaller configurations vs groups [was Re: Pillar and GT tools in Pharo4]

On 08/03/15 13:24, Tudor Girba wrote:
> I summarize below why I think fine grained configurations should be
> preferred to groups.

Configurations are both about dependencies and how to make something
work together, and about how something is to be used. The granularity
should be so, that changes in underlying code lead to a minimum ripple
effect in configurations. That leads to a pressure for configurations to
be as coarse grained as possible. Groups allow configurations to be much
more coarse-grained than we could otherwise support. Fine grained
configurations expose implementation detail (structure) instead of an
interface. I consider groups to be first class citizens. If they are not
currently, then we should make them so.

The fine grained configurations for GT make no sense at all to me.
The same people are working on it and the parts need to change together.

Stephan

This is one of the issues we need to avoid: having an unneeded ripple
effect. GlamourCore was updated, making it necessary to update
everything that has a hard version dependency on it. Even worse is
that there is actually no change in GlamourCore 3.0.4. This problem
gets worse the more configurations we have.

ConfigurationOfGTInspectorCore>>version203: spec
        <version: '2.0.3' imports: #('2.0-baseline' )>

        spec for: #'common' do: [
                spec blessing: #'stable'.
                spec description: 'version 2.0.3'.
                spec author: 'AndreiChis'.
                spec timestamp: '12/07/2014 13:58'.
               
                spec
                        package: 'GT-Inspector' with: 'GT-Inspector-EstebanLorenzano.271';
                        package: 'GT-InspectorExtensions-Core' with:
'GT-InspectorExtensions-Core-TudorGirba.86';
                        package: 'GT-Tests-Inspector' with: 'GT-Tests-Inspector-AndreiChis.24'.
                spec
                        project: 'GlamourCore' with: '3.0.3'. ].


ConfigurationOfGTInspectorCore>>version204: spec
        <version: '2.0.4' imports: #('2.0-baseline' )>

        spec for: #'common' do: [
                spec blessing: #'stable'.
                spec description: 'version 2.0.4'.
                spec author: 'AndreiChis'.
                spec timestamp: '12/09/2014 12:08'.
               
                spec
                        package: 'GT-Inspector' with: 'GT-Inspector-EstebanLorenzano.271';
                        package: 'GT-InspectorExtensions-Core' with:
'GT-InspectorExtensions-Core-TudorGirba.86';
                        package: 'GT-Tests-Inspector' with: 'GT-Tests-Inspector-AndreiChis.24'.
                spec
                        project: 'GlamourCore' with: '3.0.4'. ].

The same happens with the subconfigurations of GT, a change in
GTInspector leads to a change in the playground.

ConfigurationOfGTPlayGround>>version106: spec
        <version: '1.0.6' imports: #('1.0-baseline' )>

        spec for: #'common' do: [
                spec blessing: #'stable'.
                spec description: 'version 1.0.6'.
                spec author: 'AndreiChis'.
                spec timestamp: '10/06/2014 11:42'.
                spec project: 'GTInspector' with: '1.0.6'.
                spec package: 'GT-Playground' with: 'GT-Playground-TudorGirba.38'. ]


ConfigurationOfGTPlayGround>>version107: spec
        <version: '1.0.7' imports: #('1.0-baseline' )>

        spec for: #'common' do: [
                spec blessing: #'stable'.
                spec description: 'version 1.0.7'.
                spec author: 'AndreiChis'.
                spec timestamp: '10/12/2014 19:56'.
                spec project: 'GTInspector' with: '1.0.7'.
                spec package: 'GT-Playground' with: 'GT-Playground-TudorGirba.38'. ]

And this means that we are better of with configurations having
high cohesion and low coupling. And tool support for groups.

Stephan

I agree!!!!!!!!

Stef

Hi,

I summarize below why I think fine grained configurations should be preferred to groups.

The group is not a first class configuration, although it can be depended on. If you depend on a group of a configuration, it's harder to understand the consequences and it's harder to build tools for it.

Consider the graph below representing the dependencies starting from ConfigurationOfMoose #development:

It's a simple representation of dependencies, and it makes the maze of configurations easier to grasp. The interesting thing about it is that by showing a configuration node only once, you can see how multiple other projects depend on it. For example, HashTable is being depended on by two distinct configurations.

You can also see that Magritte depends on Grease, but you do not see that it only depends on the Core group. To do that, you have to look at the details of the edge.

We used to have groups in GT, however, after a while we moved to more fine grained configurations. As a consequence, you can see that GlamourCore (which used to be a group in Glamour) is being depended on by three different configurations. Using first class configurations makes tool building (like representation, navigation or release) easier.

You could argue that we could represent a Group as node, however, even then you would not be able to see dependencies between groups that reside within the same configuration because groups are not first class configurations that can explicitly define dependencies, they are just groups.

Groups might provide an apparent ease of use for quick things, but I strongly believe that they are an unessential construct and that if we would not use them, tools would become cheaper and more effective.

Cheers,

Doru

On Sun, Mar 8, 2015 at 1:14 AM, Damien Cassou <[hidden email]> wrote:

On Mar 7, 2015 4:42 AM, "Tudor Girba" <[hidden email]> wrote:
>
> Actually, I would rather prefer to create a separate ConfigurationOfPillarTools that adds the Pillar-Pharo-Tools and the PetitParser dependency. What that be Ok?

Ok for me, do as you prefer. What is your rationale?

--

www.tudorgirba.com

"Every thing has its own flow"