An Overview of Metacello available on (gem)Stone Soup

[Dale]

Here's a link for the Metacello overiew:

http://gemstonesoup.wordpress.com/2009/08/25/metacello-package-management-for-monticello/

[stephane ducasse]

Hi dale

I'm going over the tutorial and the blog entry and here are the
thoughts that passed through y mind.

- Blessing: why don't you have broken?

- When you specify a list for repositories is it not dangerous since
MC does not inforce
unique number accross repositories?

- project package. A definition of the Monticello package name and
Monticello repository from which the latest project metadata is be
loaded.
I try to understand: this is a kind of metadata repository?

- how should the pragma be interpreted
version: 1.3 attribute: #common
is defined for common

package: attribute:

what is the list of pragmas?

- for save paackages: why do you only look at dirty packages (in
scriptLoader we have to pay attention that you can get a new version
that is not dirty
so we collect dirty and new version of packages).

update package methods -> update package metadata?

- I could not get "Updates the repository group for each Monitcello
package associated with the selected version of the Metacello project
to include the repository for that package as specified in the version
spec."

I do not understand what is loads:

in add: 'Anncounement' project: 'misc' version '0.233' load
{ 'Gemestone-Release}

Is it require?

Now I will read the tutorial lessons,

Stef

[stephane ducasse]

I'm reading the tutorial and it is cool.
Here are some notes I took.

Now do you think that what you call inheritance between versionSpec is
a good way to share information.

I though that I would define in version01 the repository and other
common info
and this is cool

Now what happens is I want to change it I can override it in the
following versionxx

do you have a way to clone a new version without its father information?
It could be good when you we not want to load all the information and
execute a lot of methods.
I'm thinking about release pharo or moose with metacello and thinking
that I would like to have a clean release version spec.

in lesson blessing
MetacelloTutorialProject latestVersion: #development:.

-> MetacelloTutorialProject latestVersion: #development.

lesson10Doits
this is not clear how to define pre/post

is it not confusing to use the same method selector for defining
package dependencies and project dependencies?
May be I got confused and could not sopt that the receiver was a
packge and a project spec.

- when I'm executing
MetacelloTutorialSecondProject load: '3.1'.
I see a lot of garbage been generated and I'm not sure it is normal

Stef

[Dale Henrichs]

Stef,

I'll reply to your 2 emails with 1 reply per mail, since some of your comments will have simple answers and some of your comments may turn into a longer thread.

----- "stephane ducasse" <stephane...@gmail.com> wrote:

| - Blessing: why don't you have broken?

Good idea, in 0.16 I've added #broken as an anti-filter along with #development ...

Dale

[Dale Henrichs]

----- "stephane ducasse" <stephane...@gmail.com> wrote:

| - project package. A definition of the Monticello package name and
| Monticello repository from which the latest project metadata is be
| loaded.
| I try to understand: this is a kind of metadata repository?

Yes. The _project package_ is a package/repository specification for where the metadata is stored. In practice I expect the metadata for a project to be stored in the repository where the project code is stored.

For the project metadata, I think it is important that there be an explicit declaration for where the primary source of metadata is located. Since we're using Monticello, it is entirely legal to load the metadata from any old repository, but when it comes to looking for information on the latest version, the _project package_ needs to be independently defined.

Dale

[Dale Henrichs]

----- "stephane ducasse" <stephane...@gmail.com> wrote:

| - how should the pragma be interpreted
| version: 1.3 attribute: #common
| is defined for common
|
| package: attribute:
|
| what is the list of pragmas?

'MetacelloMCProject instance pragmaKeywords' provides the list of pragmas:

#version:attribute:
#blessing:attribute:
#description:attribute:
#required:attribute:
#groups:attribute:
#doits:attribute:
#projectPackage:attribute:
#packages:attribute:
#repositories:attribute:

The #version:attribute: pragma defines the 'base' versionSpec for a version. Then there is one pragma per versionSpec instance variable allowing for the attribute-based specification of the individual versionSpec instance variables.

So,
version: '1.3' attribute: #common

defines the #common base versionSpec information for version '1.3'.

packages: '1.3' attribute: #common

defines the #common packages for version '1.3' ... the packagesSpec is applied to the #common base versionSpec.

packages: '1.3' attribute: #pharo

defines the #pharo packages for version '1.3' on Pharo the packagesSpec is applied to the #common base versionSpec.

blessing: '1.3' attribute: #pharo

Allows you to specify a platform-specific blessing for a particular version.

Dale

[Dale Henrichs]

----- "stephane ducasse" <stephane...@gmail.com> wrote:

| in lesson blessing
| MetacelloTutorialProject latestVersion: #development:.
|
| -> MetacelloTutorialProject latestVersion: #development.

Ah, good catch, the fix will be in 0.16

Dale

[Dale Henrichs]

----- "stephane ducasse" <stephane...@gmail.com> wrote:

| is it not confusing to use the same method selector for defining
| package dependencies and project dependencies?
| May be I got confused and could not sopt that the receiver was a
| packge and a project spec.
|

Okay, I'm not completely clear on what part of the tutorial you are referring to (the two required project lessons)...I will spend some time and think about a better way to describe the functionality...I think I probably need to expand the example to cover smaller pieces of functionality at a time ... there _is_ quite a bit going on with project dependencies...

|
| - when I'm executing
| MetacelloTutorialSecondProject load: '3.1'.
| I see a lot of garbage been generated and I'm not sure it is normal

Was the garbage in the Transcript or in the printout? ... I do know that I am stretching the limits of what the Null loader can do when asking it to demonstrate project dependencies without real packages being loaded, so that may be why you are seeing garbage...

I'll take both of these comments to mean that the final few lessons aren't clear enough and need to be reworked.

Thanks for taking the time to give me good feedback.

Dale

[stephane ducasse]

I agree!

[stephane ducasse]

On Aug 27, 2009, at 1:59 AM, Dale Henrichs wrote:

>
>
> ----- "stephane ducasse" <stephane...@gmail.com> wrote:
>
> | is it not confusing to use the same method selector for defining
> | package dependencies and project dependencies?
> | May be I got confused and could not sopt that the receiver was a
> | packge and a project spec.
> |
>
> Okay, I'm not completely clear on what part of the tutorial you are
> referring to (the two required project lessons)...I will spend some
> time and think about a better way to describe the functionality...I
> think I probably need to expand the example to cover smaller pieces
> of functionality at a time ... there _is_ quite a bit going on with
> project dependencies...
>
> |
> | - when I'm executing
> | MetacelloTutorialSecondProject load: '3.1'.
> | I see a lot of garbage been generated and I'm not sure it is normal
>
> Was the garbage in the Transcript or in the printout?

no I saw the mouse cursor changing to show several gcs.

[Damien Pollet]

On Wed, Aug 26, 2009 at 23:50, Dale Henrichs<dale.h...@gemstone.com> wrote:
> | - Blessing: why don't you have broken?
>
> Good idea, in 0.16 I've added #broken as an anti-filter along with #development ...

How would you bless such a version, since it will likely have already
been released as something else when someone realizes it's broken ?
Would simply changing that version description and re-commit the
metadata work?

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

[Dale Henrichs]

----- "Damien Pollet" <damien...@gmail.com> wrote:

| On Wed, Aug 26, 2009 at 23:50, Dale
| Henrichs<dale.h...@gemstone.com> wrote:
| > | - Blessing: why don't you have broken?
| >
| > Good idea, in 0.16 I've added #broken as an anti-filter along with
| #development ...
|
| How would you bless such a version, since it will likely have already
| been released as something else when someone realizes it's broken ?
| Would simply changing that version description and re-commit the
| metadata work?

Yes ... I think the blessing is the one versionSpec attribute that is safe to change after release...Once a version has transitioned out of developemnt,then nothing else should be changed ...

Dale