[ENH]: Group meta-info

There was a great discussion (that I think is still relevant and unresolved; see http://forum.world.st/About-Configurations-td2287011.html) that included the following juicy bit (http://forum.world.st/About-Configurations-tp2287011p2287048.html):
    WebClient Options:
                [x] Code (required)
                [x] Tests (optional)
                [x] Documentation (optional)

I immediately thought about it when loading Versionner via the Metacello configuration. Imagine that I am a naive user that wants to load and use Versionner...

Versionner declares the following groups:
        spec group: 'Core' with: #('Versionner-Core-Model' 'Versionner-Core-Commands' 'Versionner-Core-Announcements' 'Versionner-Cache').
        spec group: 'GLM' with: #('Versionner-GLM-Browser').
        spec group: 'Spec' with: #('Versionner-Spec-Browser').

The structure of each group is very clear. What's missing is its relationship to the project and the other groups. Currently, this is made up on the class-side, with #loadWithGlamour and #loadWithSpec. As a naive user, this is complicated and unclear. How do I know which group(s) to load?! As Metacello tools evolve, this limitation will be even more acute.

What I want to see is something like:
  Versionner Options:
    [x] Core (required)
    [x] UI (optional)
      [ ] Glamour - stable, but soon to be replaced by spec (default)
      [x] Spec - under development

Which would require something like:
        spec group: 'Core' with: [
                spec
                        requires: #('Versionner-Core-Model' 'Versionner-Core-Commands' 'Versionner-Core-Announcements' 'Versionner-Cache');
                        beRequired ].
        spec options: 'UI' with: [
                spec
                        beOptional;
                        default: 'Glamour';
                        group: 'Glamour' with: [
                                spec
                                        description: 'stable, but soon to be replaced by spec';
  requires: #('Versionner-GLM-Browser').
                        spec group: 'Spec' with: [
                                spec
                                        description: 'under development';
  requires: #('Versionner-Spec-Browser').

<OT>
In the thread, Andreas was saying that there should be a meta-layer above Metacello that deals with some logical domain concept. He called them Configurations, I think Projects. The idea was that Metacello is overkill for single-package projects (and I agree), but obviously loading packages directly is brittle. So have a domain entity which can use Metacello or whatever might be appropriate in a specific context.

I've already found the need to do this in my own images (although my meta-layer always uses Metacello underneath, which feels a little icky for 1 package). I have a SmallProject class whose instances maintain my preferred location for the ConfigurationOfXx for each project I use, as well as things like "always load #development on Pharo 2.0".
</OT>

Anyway, I think the meta-layer is a good area for discussion, but we can enrich Metacello to provide part of the functionality (user-focused meta-info explaining the relationship and purpose of the parts of the project) right now.

What do you think?

Cheers,
Sean

I can see that an additional structural element would be useful ... your example with groups/beRequired/etc looks good except that I'd rather not overload groups, I think an element with a different name should be used: modules, packets, bundles.... that way we can tell the difference between 'naked groups' and 'annotated groups'.

I'm still not clear on what your looking for in the single-package case ... as you say, loading the package directly is too brittle so you need a wrapper of some sort that can grow with the project ... the configuration is a wrapper, so I'm not sure what the "problem" is.

Have you looked at the Sample project[1]? To me the separation of the "configuration" into the BaselineOf and ConfiguraionOf addresses the "ickiness", since you can set them and forget them without having to constantly fiddle with the configuration that comes when you using mcz repositories.

Dale

[1] https://github.com/dalehenrich/sample


----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, July 5, 2012 11:57:31 AM
| Subject: [Metacello] [ENH]: Group meta-info
|
| There was a great discussion (that I think is still relevant and
| unresolved;
| see http://forum.world.st/About-Configurations-td2287011.html) that
| included
| the following juicy bit
| (http://forum.world.st/About-Configurations-tp2287011p2287048.html):
|     WebClient Options:
|                 [x] Code (required)
|                 [x] Tests (optional)
|                 [x] Documentation (optional)
|
| I immediately thought about it when loading Versionner via the
| Metacello
| configuration. Imagine that I am a naive user that wants to load and
| use
| Versionner...
|
| Versionner declares the following groups:
| spec group: 'Core' with: #('Versionner-Core-Model'
| 'Versionner-Core-Commands' 'Versionner-Core-Announcements'
| 'Versionner-Cache').
| spec group: 'GLM' with: #('Versionner-GLM-Browser').
| spec group: 'Spec' with: #('Versionner-Spec-Browser').
|
| The structure of each group is very clear. What's missing is its
| relationship to the project and the other groups. Currently, this is
| made up
| on the class-side, with #loadWithGlamour and #loadWithSpec. As a
| naive user,
| this is complicated and unclear. How do I know which group(s) to
| load?! As
| Metacello tools evolve, this limitation will be even more acute.
|
| What I want to see is something like:
|   Versionner Options:
|     [x] Core (required)
|     [x] UI (optional)
|       [ ] Glamour - stable, but soon to be replaced by spec (default)
|       [x] Spec - under development
|
| Which would require something like:
| spec group: 'Core' with: [
| spec
| requires: #('Versionner-Core-Model' 'Versionner-Core-Commands'
| 'Versionner-Core-Announcements' 'Versionner-Cache');
| beRequired ].
| spec options: 'UI' with: [
| spec
| beOptional;
| default: 'Glamour';
| group: 'Glamour' with: [
| spec
| description: 'stable, but soon to be replaced by spec';
|   requires: #('Versionner-GLM-Browser').
| spec group: 'Spec' with: [
| spec
| description: 'under development';
|   requires: #('Versionner-Spec-Browser').
|
| <OT>
| In the thread, Andreas was saying that there should be a meta-layer
| above
| Metacello that deals with some logical domain concept. He called them
| Configurations, I think Projects. The idea was that Metacello is
| overkill
| for single-package projects (and I agree), but obviously loading
| packages
| directly is brittle. So have a domain entity which can use Metacello
| or
| whatever might be appropriate in a specific context.
|
| I've already found the need to do this in my own images (although my
| meta-layer always uses Metacello underneath, which feels a little
| icky for 1
| package). I have a SmallProject class whose instances maintain my
| preferred
| location for the ConfigurationOfXx for each project I use, as well as
| things
| like "always load #development on Pharo 2.0".
| </OT>
|
| Anyway, I think the meta-layer is a good area for discussion, but we
| can
| enrich Metacello to provide part of the functionality (user-focused
| meta-info explaining the relationship and purpose of the parts of the
| project) right now.
|
| What do you think?
|
| Cheers,
| Sean
|
| --
| View this message in context:
| http://forum.world.st/ENH-Group-meta-info-tp4638605.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

I'd rather not overload groups, I think an element with a different name should be used: modules, packets,

I agree.

Dale Henrichs wrote

I'm still not clear on what your looking for in the single-package case

I'm just thinking of the case where the Metacello bootstrap takes ~10x as long as the package load. This is getting better, and I've gotten used to it, but I initially found it very frustrating and understand where others are coming from...

Dale Henrichs wrote

Have you looked at the Sample project[1]? To me the separation of the "configuration" into the BaselineOf and ConfiguraionOf addresses the "ickiness", since you can set them and forget them without having to constantly fiddle with the configuration that comes when you using mcz repositories.

No, I'll move it to the top of my list. Thanks for the reminder...

Sean

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
|
| Dale Henrichs wrote
| >
| > I'm still not clear on what your looking for in the single-package
| > case
| >
| I'm just thinking of the case where the Metacello bootstrap takes
| ~10x as
| long as the package load. This is getting better, and I've gotten
| used to
| it, but I initially found it very frustrating and understand where
| others
| are coming from...

ah ... I always work in an image that has Metacello pre-booted, so I forget about the long boot time, especially for a single package ... now I understand:)

Dale