Few questions about Metacello

0 views
Skip to first unread message

Bergel, Alexandre

unread,
May 28, 2009, 11:18:18 AM5/28/09
to montice...@googlegroups.com
Hi!

It appears that the notion of Package spec and Features are important.
However, they are not completely clear to me

- about PackageSpec In your example, you gave
(MetacelloPackagesSpec for: self)
addPackage: 'Morphic' file: 'Morphic-Alexandre_Bergel.306.mcz';
addPackage: 'Mondrian' file: 'Mondrian-Alexandre_Bergel.214';
addRepository: 'http://www.squeaksource.com/Mondrian' type: 'http';
addRepository: 'http://www.squeaksource.com/PharoInbox' type: 'http';
yourself

What package is loaded from where? I would have imagined a link
(package->repository)

- What is a feature? I see code like
(MetacelloFeatureSpec for: self)
featureName: 'core'
description: 'Code for Mondrian';
addPackageName: 'Mondrian';
addPackageName: 'Morphic';
yourself

What is the meaning to add package name in a feature?

- Why MetacelloMCVersionMap is not called MetacelloMCLoader or
something? As far as I can see, subclasses of MetacelloMCVersionMap
are used to define the necessary info to be able to load code.
Especially that MondrianVersionMap has a 'loadMondrian' class method.

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dale Henrichs

unread,
May 28, 2009, 12:45:26 PM5/28/09
to montice...@googlegroups.com

----- "Alexandre Bergel" <ber...@iam.unibe.ch> wrote:

| Hi!
|
| It appears that the notion of Package spec and Features are important.
|
| However, they are not completely clear to me
|
| - about PackageSpec In your example, you gave
| (MetacelloPackagesSpec for: self)
| addPackage: 'Morphic' file: 'Morphic-Alexandre_Bergel.306.mcz';
| addPackage: 'Mondrian' file: 'Mondrian-Alexandre_Bergel.214';
| addRepository: 'http://www.squeaksource.com/Mondrian' type: 'http';
| addRepository: 'http://www.squeaksource.com/PharoInbox' type: 'http';
| yourself
|
| What package is loaded from where? I would have imagined a link (package->repository)

During the actual load step, an MCRepository group is created from the list of repositories associated with the packages spec (after conditional merges etc.). Monticello then loads the package from the first repository that contains the package.

A link between the package and a repository (or repository list) isn't required, however, I am thinking that it would be useful to make it possible to associate a repository with a package. It _is_ useful to be able to recreate the repository group that is associated with the working copy.

One of the things that I haven't covered in detail is that it must be possible to replace/augment the list of repositories during a load...Some folks do not have easy access to the internet from their working environments and may create internally accessible SqueakSource repositories, or create directory repositories with the desired packages.

I think that we can have our cake and eat it too.

|
| - What is a feature? I see code like
| (MetacelloFeatureSpec for: self)
| featureName: 'core'
| description: 'Code for Mondrian';
| addPackageName: 'Mondrian';
| addPackageName: 'Morphic';
| yourself
|
| What is the meaning to add package name in a feature?

In the rewrite I have renamed feature to group and and you #addMembers: to a group. In the above example a group named 'core' is created which contains the packages named 'Mondrian' and 'Morphic'. For smaller projects groups aren't necessary and I wrote yesterday that I think groups should be optional. For larger groups it is convenient to be able to create different groups that like 'tests' that can be loaded and unloaded ...

|
| - Why MetacelloMCVersionMap is not called MetacelloMCLoader or
| something? As far as I can see, subclasses of MetacelloMCVersionMap
| are used to define the necessary info to be able to load code.
| Especially that MondrianVersionMap has a 'loadMondrian' class method.

The MetacelloMCVersionMap _is_ primarily used to access versions and it is the versions that are loaded. #loadMondrian is a a convenience method for loading the latest version of Mondrian...

With that said, I've always had trouble with naming things - witness the name 'features' that I used above when I should have used 'groups':)

I am willing to entertain suggestions for better names. The MetacelloMCVersionMap will be the most prominent class used in Metacello as nearly all of the other classes are implmentation details, so a good name here is important.

Dale

Bergel, Alexandre

unread,
May 28, 2009, 4:43:02 PM5/28/09
to montice...@googlegroups.com
Thanks for these explanations,

>
> | - What is a feature? I see code like
> | (MetacelloFeatureSpec for: self)
> | featureName: 'core'
> | description: 'Code for Mondrian';
> | addPackageName: 'Mondrian';
> | addPackageName: 'Morphic';
> | yourself
> |
> | What is the meaning to add package name in a feature?
>
> In the rewrite I have renamed feature to group and and you
> #addMembers: to a group. In the above example a group named 'core'
> is created which contains the packages named 'Mondrian' and
> 'Morphic'. For smaller projects groups aren't necessary and I wrote
> yesterday that I think groups should be optional. For larger groups
> it is convenient to be able to create different groups that like
> 'tests' that can be loaded and unloaded ...

Ok, but a group of what? Of packages you want to load?
When defining a group will be a good idea?

> | - Why MetacelloMCVersionMap is not called MetacelloMCLoader or
> | something? As far as I can see, subclasses of MetacelloMCVersionMap
> | are used to define the necessary info to be able to load code.
> | Especially that MondrianVersionMap has a 'loadMondrian' class
> method.
>
> The MetacelloMCVersionMap _is_ primarily used to access versions and
> it is the versions that are loaded. #loadMondrian is a a convenience
> method for loading the latest version of Mondrian...
>
> With that said, I've always had trouble with naming things - witness
> the name 'features' that I used above when I should have used
> 'groups':)
>
> I am willing to entertain suggestions for better names. The
> MetacelloMCVersionMap will be the most prominent class used in
> Metacello as nearly all of the other classes are implmentation
> details, so a good name here is important.


When one would want to create a subclass of MetacelloMCVersionMap? Do
you have other scenario than loading code ?

Dale Henrichs

unread,
May 28, 2009, 5:07:33 PM5/28/09
to montice...@googlegroups.com

----- "Alexandre Bergel" <ber...@iam.unibe.ch> wrote:

| Thanks for these explanations,
| >
| > | - What is a feature? I see code like
| > | (MetacelloFeatureSpec for: self)
| > | featureName: 'core'
| > | description: 'Code for Mondrian';
| > | addPackageName: 'Mondrian';
| > | addPackageName: 'Morphic';
| > | yourself
| > |
| > | What is the meaning to add package name in a feature?
| >
| > In the rewrite I have renamed feature to group and and you
| > #addMembers: to a group. In the above example a group named 'core'
|
| > is created which contains the packages named 'Mondrian' and
| > 'Morphic'. For smaller projects groups aren't necessary and I wrote
|
| > yesterday that I think groups should be optional. For larger groups
|
| > it is convenient to be able to create different groups that like
| > 'tests' that can be loaded and unloaded ...
|
| Ok, but a group of what? Of packages you want to load?
| When defining a group will be a good idea?

Groups are groups of packages or other groups within the versionMap. You would define a group when there are logical/functional subsets of packages.

You might separate your test packages from the core packages ... you might define a core group of packages that other people can use without having to load your entire project.

I guess the basic rule would be: if there is a subset of packages in your project that is useful independent of the project, then add a group. If that subset begins taking on a life of it's own, then consider splitting out the subset into a separate project/versionMap.

|
| > | - Why MetacelloMCVersionMap is not called MetacelloMCLoader or
| > | something? As far as I can see, subclasses of
| MetacelloMCVersionMap
| > | are used to define the necessary info to be able to load code.
| > | Especially that MondrianVersionMap has a 'loadMondrian' class
| > method.
| >
| > The MetacelloMCVersionMap _is_ primarily used to access versions and
|
| > it is the versions that are loaded. #loadMondrian is a a convenience
|
| > method for loading the latest version of Mondrian...
| >
| > With that said, I've always had trouble with naming things - witness
|
| > the name 'features' that I used above when I should have used
| > 'groups':)
| >
| > I am willing to entertain suggestions for better names. The
| > MetacelloMCVersionMap will be the most prominent class used in
| > Metacello as nearly all of the other classes are implmentation
| > details, so a good name here is important.
|
|
| When one would want to create a subclass of MetacelloMCVersionMap? Do
| you have other scenario than loading code ?

Each project will have it's own subclass of MetacelloMCVersionMap.

Dale

Bergel, Alexandre

unread,
May 29, 2009, 8:35:40 PM5/29/09
to montice...@googlegroups.com

> Groups are groups of packages or other groups within the versionMap.
> You would define a group when there are logical/functional subsets
> of packages.


a composite then. It makes sense to me.

Reply all
Reply to author
Forward
0 new messages