Metacello - 0.6.1 tutorial

[Dale Henrichs]

After following the instructions for loading up Metacello in the announcement email, execute the following:

MetacelloMetacelloProject updateProject.
MetacelloMetacelloProject load: '0.6.1'.

I've created a tutorial (of sorts) based on the class MetacelloExampleProjects.

Open two browsers on the MetacelloExampleProjects class. In the lefthand browser view the methods in the 'lessons' category. In the righthand browser view the '--all--' category.

Read the comments in lesson01 through lesson12...Hopefully it will introduce you to enough of the basic concepts to allow you to create your own MetacelloProjects.

Let me know if it works or not.

Dale

[Bernhard Pieber]

Hi Dale,

I just wanted to let you know that I succeeded in loading everything
and going through the lessons. Metacello definitely looks very
interesting and useful. (I am an old Envy user.)

In lesson08 the second expression includes the result. I guess this
was not intended.

I think I understand the lessons. However, I need to think a little
bit more about the API before I can give you more detailed feedback.

Thanks for your effort!

Cheers,
Bernhard

[Dale Henrichs]

Bernhard,

Thanks for taking the tutorial for a spin (I'll remove the result from lesson08 for future versions).

I never used ENVY, but I worked on Team/V at Digitalk for several years.

I'll be interested in your feedback ... I am pleased with the functionality, but I am very interested in suggestions for changes in the API that would make it easier to use and understand.

Dale

[Lukas Renggli]

Hi Dale,

thanks for this excellent tutorial.

Some questions/comments:

- The #baseline thing seems to be rather magic. Is this really needed?
Why not simply call the function returning the baseline?

MetacelloExampleProject>>version06
<version: '0.6' attribute: #common >

^self version06Baseline " <-- changed "
packages:
(self packagesSpec
add: 'Example-Core-anon.11';
add: 'Example-Tests-anon.3';
yourself);
yourself

- MetacelloExampleProject>>lession08: Why is the package order not
deterministic? I am sure that you would run into troubles when you try
to load the tests before the core code. Why not simply load in the
order specified if there are no dependencies specified?

- I don't understand the difference between #versionSpec and
#packageSpec? There seems to be some duplication (monticello version
names) between the two.

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch

[Dale Henrichs]

----- "Lukas Renggli" <ren...@gmail.com> wrote:

| Hi Dale,
|
| thanks for this excellent tutorial.
|
| Some questions/comments:
|
| - The #baseline thing seems to be rather magic. Is this really
| needed?
| Why not simply call the function returning the baseline?
|
| MetacelloExampleProject>>version06
| <version: '0.6' attribute: #common >
|
| ^self version06Baseline " <-- changed "
| packages:
| (self packagesSpec
| add: 'Example-Core-anon.11';
| add: 'Example-Tests-anon.3';
| yourself);
| yourself

The technique you suggest would certainly work.

The rationale for introducing #baseline was to cut down on the need to create methods carrying forward the defaults for each version - when nothing else was changing. Repositories and Groups tend to be defined once and then carried forward unchanged from version to version.

If #baseline is too magical, then I wouldn't have trouble dropping the concept altogether. New versions aren't created every day, so a couple extra methods here and there are probably not that big of a deal.

|
| - MetacelloExampleProject>>lession08: Why is the package order not
| deterministic? I am sure that you would run into troubles when you try
| to load the tests before the core code. Why not simply load in the
| order specified if there are no dependencies specified?

Ah, the part that is not deterministic is when you have something like the following:

PackageA
PackageB requires: PackageA
PackageC requires: PackageA
PackageD requires: PackageA

PackageA _will_ be loaded before the other packages, but since the relative order for PackageB, PackageC and PackageD is not specified, the actual order is not deterministic (at the moment).

With that said, it is probably a good idea to load packages in the order that they are defined and I can arrange to do that.

|
| - I don't understand the difference between #versionSpec and
| #packageSpec? There seems to be some duplication (monticello version
| names) between the two.

A #versionSpec is the root object for all of the version information. A full #versionSpec has the following fields:

versionString, blessing, description, groups, requiredProjects, packages,
repositories, projectPackage

A #packageSpec represents a Monticello package with the following fields:

name file repository requires afterLoad beforeLoad

The #repository field in a #packageSpec is optional. Usually all of the packages in a project are loaded from the #versionSpec repositories.

The #packages field in a #versionSpec holds onto a #packagesSpec, which is a list of #packageSpecs.

I think in the tutorial (so far), I focused on packages and repositories so the differences are not that obvious.

Unless I get some votes to keep #baseline (and some friendly debate:), I'll plan on eliminating them in version 0.7.

Thanks for the feedback,

Dale