Smalltalk › Squeak › Squeak - Dev

Metacello questions

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Andreas.Raab

Metacello questions

Hi -

I've been trying to wet my feet with Metacello a little by writing a
ConfigurationOfWebClient and in the process I've come across various
things that I don't understand or don't know how to express. The
configuration itself can be found here:

http://www.squeaksource.com/MetacelloRepository

Here are the questions I'm having:

1) #includes: vs. #requires:
What is the difference between #includes: and #requires:? They sound
entirely interchangeable, in particular after reading the tutorial which
states:

"When you use the #includes: directive, you are not only specifying
that the listed packages should be loaded when the parent package is
loaded, but that the #included: packages should be loaded _before_ any
packages that require the parent package."

I would expect that precise behavior for required packages, i.e., if Foo
requires: Bar then Bar is loaded before Foo if some other package
requires: Foo. What am I missing?

2) Why is HelpSystem not loaded?
In my configuration, baseline specifies that HelpSystem is required for
WebClient-Help:

"Documentation doesn't require Core/Tests, but HelpSystem"
spec package: 'WebClient-Help' with:[spec requires: 'HelpSystem'].

spec project: 'HelpSystem' with:[
spec
className: 'ConfigurationOfHelpSystem';
repository: 'http://www.squeaksource.com/MetacelloRepository'
].

However, when executed, Metacello goes through the motions but doesn't
actually *load* any version of HelpSystem (I can see it 'fetch' the
packages but not load them). It even calls the postLoadDoIt on it (which
fails since nothing was loaded). What am I doing wrong?

3) When exactly is HelpSystem loaded?

What I'm wondering about in the above is that HelpSystem should only be
loaded if WebClient-Help is being loaded. Is this implicitly part of
specifying a 'project' instead of a 'package'? Or is there some other
way of specifying that?

I guess really the question here is what entities get loaded implicitly
simply by declaring them (packages for sure, any others?) and what
entities need to be 'required' in order to be loaded?

4) How does one define dependencies that differ based on platform?

In WebClient, the WebClient-HTTP package requires WebClient-Core and
-only for: #pharo- also WebClient-Pharo. How does one express that
there's an additional dependency for WebClient-HTTP that only exists
for: #pharo? The config currently specifies:

spec for: #common do:[
" ... "
spec package: 'WebClient-HTTP' with:[spec requires: 'WebClient-Core'].
" ... "
].

spec for: #pharo do:[
"Just the fact it exists; no requirements here"
spec package: 'WebClient-Pharo'.
].

Which means that WebClient-Pharo will be loaded on Pharo by default but
it's missing the fact that WebClient-Pharo is in fact a requirement for
WebClient-HTTP (but only on that platform). How is that best expressed?

5) Bootstrapping Metacello?

I found that most of the ConfigurationsOfXXX include some code to
'bootstrap' Metacello in some form. There appear to be variants on the
code; is there a "canonical bootstrap method" that should be used?

6) A standard Configuration template?

The Metacello tutorial is very useful as far as the configuration goes
but it falls short of getting into the details of what it means to
provide a 'working' configuration. Testing the configuration isn't
covered (is there a way to get back to a 'clean' state?); bootstrapping
isn't covered; the meaning of #isMetacelloConfig,
#metacelloVesion:loads:, #lastMetacelloVersionLoad and several other
-seemingly random- methods that can be found on most -but not all- of
the configurations. There is no indication on what these do, if they're
required, recommended, or optional. Is there some 'standard'
Configuration template that people can use to avoid guessing about which
parts of the boilerplate to copy from some other configuration?

That's it for now. Thanks for any insights on any of these issues.

Cheers,
- Andreas

Andreas.Raab

Re: Metacello questions

On 5/5/2010 11:36 PM, Torsten Bergmann wrote:
> Just have a look at ConfigurationOfSQLite3 for a simple
> example. This one has a "project dependency" on ConfigurationOfFFI.
>
> If you want Help system project to be loaded in your configurartion
> you need to define it in the baselineXXX method and set a specific
> version of the project in your own #versionXXX method

Thanks. Does that mean the documentation is just wrong then? It says

MetacelloReferenceConfig>>baseline10:

"... snip ..."

spec
"Create or update a project reference"
project: 'UI Support' with: [
"One or more of the following attributes may be defined or changed"
spec
"Name of config class (i.e., ConfigurationOfXXX)"
className: 'ConfigurationOfUI';
"Version of project to be loaded. if theversionString is not
specified, then the latest version of the project is used."
versionString: '1.0';

This last comment made me assume that not providing a version would be
enough to make Metacello load the latest version. Also, the reference
config has no #version: anywhere related to the project dependency. Oh,
and what's the difference between #version: (SQLite3) and
#versionString: (MetacelloReferenceConfig)?

Cheers,
- Andreas

Dale

Re: Metacello questions

In reply to this post by Andreas.Raab

Andreas,

I'm going to be in meetings all day long, but I do have an answer for question #1 ... I'll reply in more detail to the other questions as I get time.

1) #includes: vs. #requires:

I've submitted Issue 76 (http://code.google.com/p/metacello/issues/detail?id=76) about improving the documentation for #includes: vs. #requires:.

Let's assume that we have package A that #requires: package B and #includes: package C.

If one #loads: package A, the the load order would be:

B, A, C

So the immediate distinction is that B will be loaded _before_ A due to the #requires: and C will be loaded due to the #includes:. Typically an included package will require the parent (i.e., package C requires: package A).

The utility for #includes: comes into play another package #requires: package A. In the case where package D #requires: A, the load order for a #loads: D would be:

B, A, C, D

Two things are happening, first is the obvious that package C is included before package D. Secondly, there is in implicit #requires: from D to C (i.e. D #requires: C is implied).

#includes is used quite extensively for Seaside30 where an expression like the following is used:

spec for: #common do: [
spec
package: 'Javascript-Core'
with: [ spec requires: #('Seaside-Core' 'Seaside-Canvas' ). ];
package: 'JQuery-Core'
with: [ spec requires: #('Javascript-Core' ). ]].
spec for: #squeakCommon do: [
spec
package: 'Javascript-Core'
with: [ spec includes: #('Javascript-Pharo-Core' ) ]].

'JQuery-Core' requires: 'Javascript-Core', but when 'Javascript-Core' is required. By using includes, we only need to inform 'Javascript-Core' to drag 'Javascript-Pharo-Core' along with it.

Whereas if we only had the #requires: mechanism, we'd need to duplicate every 'Javascript-Core' #requires: with a #requires: for 'Javascript-Pharo-Core'

Dale

Teleplacer wrote

Hi -

I've been trying to wet my feet with Metacello a little by writing a
ConfigurationOfWebClient and in the process I've come across various
things that I don't understand or don't know how to express. The
configuration itself can be found here:

http://www.squeaksource.com/MetacelloRepository

Here are the questions I'm having:

1) #includes: vs. #requires:
What is the difference between #includes: and #requires:? They sound
entirely interchangeable, in particular after reading the tutorial which
states:

"When you use the #includes: directive, you are not only specifying
that the listed packages should be loaded when the parent package is
loaded, but that the #included: packages should be loaded _before_ any
packages that require the parent package."

I would expect that precise behavior for required packages, i.e., if Foo
requires: Bar then Bar is loaded before Foo if some other package
requires: Foo. What am I missing?

2) Why is HelpSystem not loaded?
In my configuration, baseline specifies that HelpSystem is required for
WebClient-Help:

"Documentation doesn't require Core/Tests, but HelpSystem"
spec package: 'WebClient-Help' with:[spec requires: 'HelpSystem'].

spec project: 'HelpSystem' with:[
spec
className: 'ConfigurationOfHelpSystem';
repository: 'http://www.squeaksource.com/MetacelloRepository'
].

However, when executed, Metacello goes through the motions but doesn't
actually *load* any version of HelpSystem (I can see it 'fetch' the
packages but not load them). It even calls the postLoadDoIt on it (which
fails since nothing was loaded). What am I doing wrong?

3) When exactly is HelpSystem loaded?

What I'm wondering about in the above is that HelpSystem should only be
loaded if WebClient-Help is being loaded. Is this implicitly part of
specifying a 'project' instead of a 'package'? Or is there some other
way of specifying that?

I guess really the question here is what entities get loaded implicitly
simply by declaring them (packages for sure, any others?) and what
entities need to be 'required' in order to be loaded?

4) How does one define dependencies that differ based on platform?

In WebClient, the WebClient-HTTP package requires WebClient-Core and
-only for: #pharo- also WebClient-Pharo. How does one express that
there's an additional dependency for WebClient-HTTP that only exists
for: #pharo? The config currently specifies:

spec for: #common do:[
" ... "
spec package: 'WebClient-HTTP' with:[spec requires: 'WebClient-Core'].
" ... "
].

spec for: #pharo do:[
"Just the fact it exists; no requirements here"
spec package: 'WebClient-Pharo'.
].

Which means that WebClient-Pharo will be loaded on Pharo by default but
it's missing the fact that WebClient-Pharo is in fact a requirement for
WebClient-HTTP (but only on that platform). How is that best expressed?

5) Bootstrapping Metacello?

I found that most of the ConfigurationsOfXXX include some code to
'bootstrap' Metacello in some form. There appear to be variants on the
code; is there a "canonical bootstrap method" that should be used?

6) A standard Configuration template?

The Metacello tutorial is very useful as far as the configuration goes
but it falls short of getting into the details of what it means to
provide a 'working' configuration. Testing the configuration isn't
covered (is there a way to get back to a 'clean' state?); bootstrapping
isn't covered; the meaning of #isMetacelloConfig,
#metacelloVesion:loads:, #lastMetacelloVersionLoad and several other
-seemingly random- methods that can be found on most -but not all- of
the configurations. There is no indication on what these do, if they're
required, recommended, or optional. Is there some 'standard'
Configuration template that people can use to avoid guessing about which
parts of the boilerplate to copy from some other configuration?

That's it for now. Thanks for any insights on any of these issues.

Cheers,
- Andreas

Andreas.Raab

Re: Metacello questions

On 5/6/2010 9:55 AM, Dale wrote:
> I'm going to be in meetings all day long, but I do have an answer for
> question #1 ... I'll reply in more detail to the other questions as I get
> time.

No prob, take your time, we're all busy :-)

> 1) #includes: vs. #requires:
>
[... snip ...]

>
> #includes is used quite extensively for Seaside30 where an expression like
> the following is used:
>
> spec for: #common do: [
> spec
> package: 'Javascript-Core'
> with: [ spec requires: #('Seaside-Core' 'Seaside-Canvas' ). ];
> package: 'JQuery-Core'
> with: [ spec requires: #('Javascript-Core' ). ]].
> spec for: #squeakCommon do: [
> spec
> package: 'Javascript-Core'
> with: [ spec includes: #('Javascript-Pharo-Core' ) ]].
>
> 'JQuery-Core' requires: 'Javascript-Core', but when 'Javascript-Core' is
> required. By using includes, we only need to inform 'Javascript-Core' to
> drag 'Javascript-Pharo-Core' along with it.

Go it. So basically a package in #includes: is loaded *after* the
package it is included by, but *before* any other package that required
the former. My head is spinning....

> Whereas if we only had the #requires: mechanism, we'd need to duplicate
> every 'Javascript-Core' #requires: with a #requires: for
> 'Javascript-Pharo-Core'

How so? It seems to me, that the following should be equivalent, no?

spec for: #squeakCommon do:[
"Javascript-Core-Top is a pseudo target"
spec package: 'Javascript-Core-Top'
with: [spec requires: #(JavaScript-Pharo-Core)]
"And be explicit about load order"
spec package: 'Javascript-Pharo-Core'
with: [spec requires: #(JavaScript-Core)]
].

spec for: #common do:[
"Pseudo-top always depends on actual Javascript-Core"
spec package: 'Javascript-Core-Top
with: [spec requires: #(JavaScript-Core)]

"standard Javascript-Core dependencies"
spec
package: 'Javascript-Core'
with: [ spec requires: #('Seaside-Core' 'Seaside-Canvas' ). ].

"Now make JQuery-Core depending on the pseudo package"
spec package: 'JQuery-Core'
with:[spec requires: #('Javascript-Core-Top')].
].

Is there any difference?

Cheers,
- Andreas

> Teleplacer wrote:
>>
>> Hi -
>>
>> I've been trying to wet my feet with Metacello a little by writing a
>> ConfigurationOfWebClient and in the process I've come across various
>> things that I don't understand or don't know how to express. The
>> configuration itself can be found here:
>>
>> http://www.squeaksource.com/MetacelloRepository
>>
>> Here are the questions I'm having:
>>
>> 1) #includes: vs. #requires:
>> What is the difference between #includes: and #requires:? They sound
>> entirely interchangeable, in particular after reading the tutorial which
>> states:
>>
>> "When you use the #includes: directive, you are not only specifying
>> that the listed packages should be loaded when the parent package is
>> loaded, but that the #included: packages should be loaded _before_ any
>> packages that require the parent package."
>>
>> I would expect that precise behavior for required packages, i.e., if Foo
>> requires: Bar then Bar is loaded before Foo if some other package
>> requires: Foo. What am I missing?
>>
>> 2) Why is HelpSystem not loaded?
>> In my configuration, baseline specifies that HelpSystem is required for
>> WebClient-Help:
>>
>> "Documentation doesn't require Core/Tests, but HelpSystem"
>> spec package: 'WebClient-Help' with:[spec requires: 'HelpSystem'].
>>
>> spec project: 'HelpSystem' with:[
>> spec
>> className: 'ConfigurationOfHelpSystem';
>> repository: 'http://www.squeaksource.com/MetacelloRepository'
>> ].
>>
>> However, when executed, Metacello goes through the motions but doesn't
>> actually *load* any version of HelpSystem (I can see it 'fetch' the
>> packages but not load them). It even calls the postLoadDoIt on it (which
>> fails since nothing was loaded). What am I doing wrong?
>>
>> 3) When exactly is HelpSystem loaded?
>>
>> What I'm wondering about in the above is that HelpSystem should only be
>> loaded if WebClient-Help is being loaded. Is this implicitly part of
>> specifying a 'project' instead of a 'package'? Or is there some other
>> way of specifying that?
>>
>> I guess really the question here is what entities get loaded implicitly
>> simply by declaring them (packages for sure, any others?) and what
>> entities need to be 'required' in order to be loaded?
>>
>> 4) How does one define dependencies that differ based on platform?
>>
>> In WebClient, the WebClient-HTTP package requires WebClient-Core and
>> -only for: #pharo- also WebClient-Pharo. How does one express that
>> there's an additional dependency for WebClient-HTTP that only exists
>> for: #pharo? The config currently specifies:
>>
>> spec for: #common do:[
>> " ... "
>> spec package: 'WebClient-HTTP' with:[spec requires: 'WebClient-Core'].
>> " ... "
>> ].
>>
>> spec for: #pharo do:[
>> "Just the fact it exists; no requirements here"
>> spec package: 'WebClient-Pharo'.
>> ].
>>
>> Which means that WebClient-Pharo will be loaded on Pharo by default but
>> it's missing the fact that WebClient-Pharo is in fact a requirement for
>> WebClient-HTTP (but only on that platform). How is that best expressed?
>>
>> 5) Bootstrapping Metacello?
>>
>> I found that most of the ConfigurationsOfXXX include some code to
>> 'bootstrap' Metacello in some form. There appear to be variants on the
>> code; is there a "canonical bootstrap method" that should be used?
>>
>> 6) A standard Configuration template?
>>
>> The Metacello tutorial is very useful as far as the configuration goes
>> but it falls short of getting into the details of what it means to
>> provide a 'working' configuration. Testing the configuration isn't
>> covered (is there a way to get back to a 'clean' state?); bootstrapping
>> isn't covered; the meaning of #isMetacelloConfig,
>> #metacelloVesion:loads:, #lastMetacelloVersionLoad and several other
>> -seemingly random- methods that can be found on most -but not all- of
>> the configurations. There is no indication on what these do, if they're
>> required, recommended, or optional. Is there some 'standard'
>> Configuration template that people can use to avoid guessing about which
>> parts of the boilerplate to copy from some other configuration?
>>
>> That's it for now. Thanks for any insights on any of these issues.
>>
>> Cheers,
>> - Andreas
>>
>>
>>
>

Dale

Re: Metacello questions

In reply to this post by Andreas.Raab

Teleplacer wrote

On 5/5/2010 11:36 PM, Torsten Bergmann wrote:
> Just have a look at ConfigurationOfSQLite3 for a simple
> example. This one has a "project dependency" on ConfigurationOfFFI.
>
> If you want Help system project to be loaded in your configurartion
> you need to define it in the baselineXXX method and set a specific
> version of the project in your own #versionXXX method

Thanks. Does that mean the documentation is just wrong then? It says

MetacelloReferenceConfig>>baseline10:

"... snip ..."

spec
"Create or update a project reference"
project: 'UI Support' with: [
"One or more of the following attributes may be defined or changed"
spec
"Name of config class (i.e., ConfigurationOfXXX)"
className: 'ConfigurationOfUI';
"Version of project to be loaded. if theversionString is not
specified, then the latest version of the project is used."
versionString: '1.0';

This last comment made me assume that not providing a version would be
enough to make Metacello load the latest version. Also, the reference
config has no #version: anywhere related to the project dependency. Oh,
and what's the difference between #version: (SQLite3) and
#versionString: (MetacelloReferenceConfig)?

Cheers,
- Andreas

Andreas,

The documentation is correct and your understanding is correct ... at the moment I'm not exactly sure why the Help System is not loaded in your case ... if you could share your complete config, what version of Squeak you are working with and the expression you use to load (privately if you want), I might be able to figure out the answer to your question...

Dale

Andreas.Raab

Re: Metacello questions

On 5/6/2010 10:29 AM, Dale wrote:
> The documentation is correct and your understanding is correct ... at the
> moment I'm not exactly sure why the Help System is not loaded in your case
> ... if you could share your complete config, what version of Squeak you are
> working with and the expression you use to load (privately if you want), I
> might be able to figure out the answer to your question...

Tried both on Squeak 4.1 and Pharo 1.0 with the same results. Here is
the script for Squeak:

(Installer repository: 'http://seaside.gemstone.com/ss/metacello)
install: 'ConfigurationOfMetacello'.
(Smalltalk at: #ConfigurationOfMetacello) project latestVersion load.

(Installer repository: 'http://www.squeaksource.com/MetacelloRepository)
install: 'ConfigurationOfWebClient'.
(Smalltalk at: #ConfigurationOfWebClient) project latestVersion load.

Again, the strange thing is that it 'fetches' the right files but
doesn't load them.

Cheers,
- Andreas

Dale

Re: Metacello questions

In reply to this post by Andreas.Raab

Teleplacer wrote

On 5/6/2010 9:55 AM, Dale wrote:
<snip>
> #includes is used quite extensively for Seaside30 where an expression like
> the following is used:
>
> spec for: #common do: [
> spec
> package: 'Javascript-Core'
> with: [ spec requires: #('Seaside-Core' 'Seaside-Canvas' ). ];
> package: 'JQuery-Core'
> with: [ spec requires: #('Javascript-Core' ). ]].
> spec for: #squeakCommon do: [
> spec
> package: 'Javascript-Core'
> with: [ spec includes: #('Javascript-Pharo-Core' ) ]].
>

<snip>

> Whereas if we only had the #requires: mechanism, we'd need to duplicate
> every 'Javascript-Core' #requires: with a #requires: for
> 'Javascript-Pharo-Core'

How so? It seems to me, that the following should be equivalent, no?

spec for: #squeakCommon do:[
"Javascript-Core-Top is a pseudo target"
spec package: 'Javascript-Core-Top'
with: [spec requires: #(JavaScript-Pharo-Core)]
"And be explicit about load order"
spec package: 'Javascript-Pharo-Core'
with: [spec requires: #(JavaScript-Core)]
].

spec for: #common do:[
"Pseudo-top always depends on actual Javascript-Core"
spec package: 'Javascript-Core-Top
with: [spec requires: #(JavaScript-Core)]

"standard Javascript-Core dependencies"
spec
package: 'Javascript-Core'
with: [ spec requires: #('Seaside-Core' 'Seaside-Canvas' ). ].

"Now make JQuery-Core depending on the pseudo package"
spec package: 'JQuery-Core'
with:[spec requires: #('Javascript-Core-Top')].
].

Is there any difference?

Andreas,

The difference is that you introduced the package 'Javascript-Core-Top' and that package doesn't exist:) So the #includes: directive means that you don't have to introduce "artificial" targets that perform no other function than act as a dependency target.

Keep in mind that over time a project may evolve to the point where you need to add a "new dependency target" and if you have to add a new target, other projects that depend upon this project and may reference the "old dependency target" and will not function correctly moving forward.

The #includes: directive allows you to "add packages to the original dependency target" without changing the structure of your project...

Dale

Dale

Re: Metacello questions

In reply to this post by Andreas.Raab

Andreas,

You have bumped into a bug in Metacello 1.0-beta.26. I discovered the bug a couple of weeks ago while using Metacello in GLASS so the bug is fixed in Metacello 1.0-beta.26.1. 1.0-beta.26.1 is under development (#development blessing) so is not loaded by #latestVersion. I am a couple of days away from releasing 1.0-beta.26.1 but if you want to try it out, you can explicitly load 1.0-beta.26.1 with this expression:

(ConfigurationOfMetacello project version: '1.0-beta.26.1') load

The bug was triggered because ConfigurationOfWebClient uses an #atomic load and ConfigurationOfHelpBrowser uses #linear loads ... the help browser packages were missed in the transition.

The default configuration template sets the loadType to #linear, so you hit this specifically because you didn't use the template, which relates to your other questions so I'll answer them in another letter.

Dale
----- "Andreas Raab" <[hidden email]> wrote:

| On 5/6/2010 10:29 AM, Dale wrote:
| > The documentation is correct and your understanding is correct ...
| at the
| > moment I'm not exactly sure why the Help System is not loaded in
| your case
| > ... if you could share your complete config, what version of Squeak
| you are
| > working with and the expression you use to load (privately if you
| want), I
| > might be able to figure out the answer to your question...
|
| Tried both on Squeak 4.1 and Pharo 1.0 with the same results. Here is
|
| the script for Squeak:
|
| (Installer repository: 'http://seaside.gemstone.com/ss/metacello)
| install: 'ConfigurationOfMetacello'.
| (Smalltalk at: #ConfigurationOfMetacello) project latestVersion load.
|
| (Installer repository:
| 'http://www.squeaksource.com/MetacelloRepository)
| install: 'ConfigurationOfWebClient'.
| (Smalltalk at: #ConfigurationOfWebClient) project latestVersion load.
|
|
| Again, the strange thing is that it 'fetches' the right files but
| doesn't load them.
|
| Cheers,
| - Andreas

Mariano Martinez Peck

Re: Metacello questions

In reply to this post by Andreas.Raab

On Thu, May 6, 2010 at 7:06 AM, Andreas Raab <[hidden email]> wrote:

Hi -

I've been trying to wet my feet with Metacello a little by writing a ConfigurationOfWebClient and in the process I've come across various things that I don't understand or don't know how to express. The configuration itself can be found here:

http://www.squeaksource.com/MetacelloRepository

Here are the questions I'm having:

1) #includes: vs. #requires:
What is the difference between #includes: and #requires:? They sound entirely interchangeable, in particular after reading the tutorial which states:

"When you use the #includes: directive, you are not only specifying that the listed packages should be loaded when the parent package is loaded, but that the #included: packages should be loaded _before_ any packages that require the parent package."

I would expect that precise behavior for required packages, i.e., if Foo requires: Bar then Bar is loaded before Foo if some other package requires: Foo. What am I missing?

2) Why is HelpSystem not loaded?
In my configuration, baseline specifies that HelpSystem is required for WebClient-Help:

"Documentation doesn't require Core/Tests, but HelpSystem"
spec package: 'WebClient-Help' with:[spec requires: 'HelpSystem'].

spec project: 'HelpSystem' with:[
spec
className: 'ConfigurationOfHelpSystem';
repository: 'http://www.squeaksource.com/MetacelloRepository'
].

However, when executed, Metacello goes through the motions but doesn't actually *load* any version of HelpSystem (I can see it 'fetch' the packages but not load them). It even calls the postLoadDoIt on it (which fails since nothing was loaded). What am I doing wrong?

Hi Andreas, I am not sure, but did you try setting also the file:

   "Documentation doesn't require Core/Tests, but HelpSystem"
spec package: 'WebClient-Help' with:[spec requires: 'HelpSystem'].

spec project: 'HelpSystem' with:[
spec
className: 'ConfigurationOfHelpSystem';
repository: 'http://www.squeaksource.com/MetacelloRepository';
                               file: 'ConfigurationOfHelpSystem';
].

I saw in your final version you added a version: '1.1' and I saw you put a comment saying that's a Metacello bug. It's weird since version: shouldn't be necessary there.

You should put it in the version.

spec
            package: 'WebClient-Core' with: 'WebClient-Core-ar.16';
            package: 'WebClient-Tests' with: 'WebClient-Tests-ar.7';
            package: 'WebClient-Help' with: 'WebClient-Help-ar.5';
            package: 'WebClient-HTTP' with: 'WebClient-HTTP-ar.1'.
spec
            project: 'HelpSystem' with: '1.1'.

3) When exactly is HelpSystem loaded?

What I'm wondering about in the above is that HelpSystem should only be loaded if WebClient-Help is being loaded. Is this implicitly part of specifying a 'project' instead of a 'package'? Or is there some other way of specifying that?

I guess really the question here is what entities get loaded implicitly simply by declaring them (packages for sure, any others?) and what entities need to be 'required' in order to be loaded?

If you don't define groups in your configuration, it will load by default all the declarations: packages and projects.

If you want to change that, you can add to your conf something like this:

spec
            group: 'default' with: #('Core' );
            group: 'Core' with: #( 'WebClient-Core' "...");
            group: 'Tests' with: #( 'WebClient-Tests' "...");
            "....."
            yourself.

With that, when you call "load" it will only load Core. Then, you can do this:

(ConfigurationOfWebClient project version: '1.0') load: 'Test'
or
(ConfigurationOfWebClient project version: '1.0') load: 'WebClient-Core'
or
(ConfigurationOfWebClient project version: '1.0') load: {'WebClient-Core' 'WebClient-HTTP'}.

The parameter to load: can be a package name, a group or an an array of them.

4) How does one define dependencies that differ based on platform?

In WebClient, the WebClient-HTTP package requires WebClient-Core and -only for: #pharo- also WebClient-Pharo. How does one express that there's an additional dependency for WebClient-HTTP that only exists for: #pharo? The config currently specifies:

spec for: #common do:[
" ... "
spec package: 'WebClient-HTTP' with:[spec requires: 'WebClient-Core'].
" ... "
].

spec for: #pharo do:[
"Just the fact it exists; no requirements here"
spec package: 'WebClient-Pharo'.
].

The only thing that comes to my mind now is to do:

spec for: #common do:[
" ... "
spec package: 'WebClient-HTTP' with:[spec requires: 'WebClient-Core'].
" ... "
].

spec for: #pharo do:[
spec package: 'WebClient-HTTP' with:[spec requires: { 'WebClient-Core' 'WebClient-Pharo'} ].

].

Which means that WebClient-Pharo will be loaded on Pharo by default but it's missing the fact that WebClient-Pharo is in fact a requirement for WebClient-HTTP (but only on that platform). How is that best expressed?

5) Bootstrapping Metacello?

I found that most of the ConfigurationsOfXXX include some code to 'bootstrap' Metacello in some form. There appear to be variants on the code; is there a "canonical bootstrap method" that should be used?

6) A standard Configuration template?

The Metacello tutorial is very useful as far as the configuration goes but it falls short of getting into the details of what it means to provide a 'working' configuration. Testing the configuration isn't covered (is there a way to get back to a 'clean' state?); bootstrapping isn't covered; the meaning of #isMetacelloConfig, #metacelloVesion:loads:, #lastMetacelloVersionLoad and several other -seemingly random- methods that can be found on most -but not all- of the configurations. There is no indication on what these do, if they're required, recommended, or optional. Is there some 'standard' Configuration template that people can use to avoid guessing about which parts of the boilerplate to copy from some other configuration?

That's it for now. Thanks for any insights on any of these issues.

Cheers,
- Andreas

Mariano Martinez Peck

Re: Metacello questions

GRRRR gmail shortcuts...

4) How does one define dependencies that differ based on platform?

In WebClient, the WebClient-HTTP package requires WebClient-Core and -only for: #pharo- also WebClient-Pharo. How does one express that there's an additional dependency for WebClient-HTTP that only exists for: #pharo? The config currently specifies:

spec for: #common do:[
" ... "
spec package: 'WebClient-HTTP' with:[spec requires: 'WebClient-Core'].
" ... "
].

spec for: #pharo do:[
"Just the fact it exists; no requirements here"
spec package: 'WebClient-Pharo'.
].

The only thing that comes to my mind now is to do:

spec for: #common do:[
" ... "
spec package: 'WebClient-HTTP' with:[spec requires: 'WebClient-Core'].
" ... "
].

spec for: #pharo do:[
spec package: 'WebClient-HTTP' with:[spec requires: { 'WebClient-Core' 'WebClient-Pharo'};

spec package: 'WebClient-Pharo'.
].

].

Cheers

Mariano