On 6/24/16 6:28 AM, Norbert Hartl wrote:

I have a seaside project that will be installed in a typical fashion headless on a server somewhere on the net. The project is in its final stage so I started to care about the size of the image. Or better: The size of the image is not my main concern but the number of packages installed. The less packages you load the better it is, it is that simple. This time I encountered a problem that I often see but this particular one explains in a very good way that how we use metacello can be improved.

In my project I load only Seaside-Core. This has the advantage of loading far less packages and I don't have the need to remove a bunch of registered web applications that registered themselves when being loaded. I make use of a bootstrap template bought somewhere on the net. I use magritte a lot so I was happy to see that there is a package called BootstrapMagritte. The package extends some magritte ui classes and overwrites some methods to add specific classes to HTML tags. Basically not very much code. What happended after I added the package as a dependency to my own project you can see here in the load directive of metacello

linear load : explicit load : 0.2.3 [ConfigurationOfBootstrapMagritte] linear load : 0.2.3 [ConfigurationOfBootstrapMagritte] linear load : 3.5.0 [ConfigurationOfMagritte3] linear load : 1.1.0 [ConfigurationOfMagritteGlamourForPharo40] load : Glamour-Presentations.issue_1126-SeanDeNigris.178 load : Glamour-Morphic-Renderer.issue_1126-SeanDeNigris.325 explicit load : 3.1.5 [ConfigurationOfSeaside3] linear load : 3.1.5 [ConfigurationOfSeaside3] explicit load : 0.26 [ConfigurationOfParasol] linear load : 0.26 [ConfigurationOfParasol] linear load : 3.2.0 [ConfigurationOfSeaside3] load : Seaside-Tests-REST-Core-EstebanMaringolo.34

This is wrong in so many ways. I load a little extensions to my web application and end up loading _all_ of seaside which loads beach parasol (a ui testing framework), _all_ of magritte which in turn loads glamour packages (a ui toolkit). So at this point I think WTF?

Why does this happen? Because the "default" group in many projects contains all of the packages and dependencies of the project. I thought at first this is wrong but in the meantime I think it is right. Whenever a configuration is loaded without additional parameters the "default" group gets loaded. This is the best scenario for newcomers (e.g. using the catalog to load). They don't know better but want to see what the package has to offer. Fine, we should support that.

For managing projects this gets annoying really quick like you can see above. It would always load all dependencies and all packages of every project that your own project depends. This is a no-go. To circumvent this a lot of people add a "core" group to their configurations (loading the essential parts). This is great because in my own project I can add a dependency to a project and load only the "core" group. This works if the dependency chain is not very long (at best it works in depth 1 ;) ). As soon as a project has two interesting groups the problem gets worse. A good example is magritte. It is useful for describing your model as well as it contains useful seaside components. The moment I add a dependency from my model package to magritte seaside I know it is wrong. I find myself sometimes duplicating dependencies just to mitigate the effect. I do something like

project: 'Magritte3Seaside' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; loads: #('Seaside' ); repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; project: 'Magritte3Core' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; loads: #('Core' ); repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ];

and… package: #'MyProject-Model-Core' with: [ spec requires: #( 'Magritte3Core' ). ]; package: #'MyProject-UI-Core' with: [ spec requires: #( 'Seaside3' 'Magritte3Seaside' 'BootstrapMagritte' ). ];

just to be able to put the right dependencies. But this way is cumbersome to do and not support by tools like Versionner.

The main problem to me is that the maintainer of the configuration defines the granularity of pieces to load forcing me to do stupid workarounds to achieve what I want. To me the problem is that the separation is not done properly. I think the logic of having loads() in the baseline and a pure string like "Magritte3Core" in the dependency spec is reversed. It should be

project: 'Magritte3' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ];

and…

package: #'MyProject-Model-Core' with: [ spec requires: #( 'Magritte3:Core' ). ]; package: #'MyProject-UI-Core' with: [ spec requires: #( 'Seaside3' 'Magritte3:Seaside' 'BootstrapMagritte' ). ];

Note the "Magritte3:Core" in the dependency spec. The meaning is that there is a dependency to Magritte3 and group Core. This way dependencies can be properly aligned. Or are there other way to deal with it?

What do you think?

Norbert Norbert,

Does the following meet your needs? project: 'Magritte3' with: [ spec className: #ConfigurationOfMagritte3; versionString: #'stable'; repository: 'http://smalltalkhub.com/mc/Magritte/Magritte3/main/' ]; project: 'Magritte3Seaside' copyFrom: 'Magritte' with: [ spec loads: #('Seaside' ) ]; project: 'Magritte3Core' copyFrom: 'Magritte' with: [ spec loads: ##('Core' ) ]; I assume the "stupid workaround" is the fact that in your example you had to specify Magritte twice? #project:copyFrom:with: has been around for a long time in Metacello and was invented to solve this particular problem ... FWIW, this feature is documented in Lesson12 of "Metacello Configuration Tutorial Part 2" in the Help Browser ... Dale