Metacell Base preview

Stef, Colin, et.al.,

I've got an initial cut at the classes[1] that I'd like to have included in the base for Pharo and Squeak. So I'd appreciate it if you'd take a look and let me know what you think. I'm still working on details (including class comments), but there's enough there for you guys to see what I have planned.

The classes ConfigurationOf and BaselineOf are intended to the be the common superclasses for Metacello configurations.

The class Metacello implements the Metacello scripting api.

Metacello will be auto-loaded when you use the api. For example the following expression:

  Metacello new
    configuration: 'Seaside30';
    version: '3.0.7';
    repository: 'http://www.squeaksource.com/Seaside30';
    load.

will auto-load Metacello and then load Seaside30.

The old Gofer/Installer scripts will still work, but moving forward I want to encourage the use of the scripting API, since it will be common across all dialects.

I'm still working on the details of the scripting api, but the api is now functional and running in both Pharo and Squeak ... I'm using travis-ci[2] to run tests against pharo (1.3) and squeak (4.3) on every Github push.

Stef and Colin, let me know which version of Pharo/Squeak you'd like to target for inclusion of the Metacello base classes and I'll add that version to the travis-ci build matrix going forward.

Dale

[1] http://seaside.gemstone.com/ss/metacello/Metacello-Base-dkh.64.mcz
[2] http://travis-ci.org/#!/dalehenrich/metacello-work

Dale Henrichs wrote

The classes ConfigurationOf and BaselineOf are intended to the be the common superclasses for Metacello configurations.

Bye bye outdated class-side methods!

Dale Henrichs wrote

The class Metacello implements the Metacello scripting api.
...
  Metacello new
    configuration: 'Seaside30';
    version: '3.0.7';
    repository: 'http://www.squeaksource.com/Seaside30';
    load.

Excellent! Very clean...

Thanks for all the hard work, Dale :)

Sean

+1.

Thanks, Dale.

Doru


On 12 Jun 2012, at 18:15, Sean P. DeNigris wrote:

--
www.tudorgirba.com

"Beauty is where we see it."

--
Mariano
http://marianopeck.wordpress.com

Mariano,

Thanks for taking the time...good questions..

comments embedded...

----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 13, 2012 5:17:08 AM
| Subject: Re: [Metacello] Metacell Base preview
|
|
|
|
| On Tue, Jun 12, 2012 at 6:03 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Stef, Colin, et.al .,
|
| I've got an initial cut at the classes[1] that I'd like to have
| included in the base for Pharo and Squeak. So I'd appreciate it if
| you'd take a look and let me know what you think. I'm still working
| on details (including class comments), but there's enough there for
| you guys to see what I have planned.
|
| The classes ConfigurationOf and BaselineOf are intended to the be the
| common superclasses for Metacello configurations.
|
| The class Metacello implements the Metacello scripting api.
|
| Metacello will be auto-loaded when you use the api. For example the
| following expression:
|
| Metacello new
| configuration: 'Seaside30';
| version: '3.0.7';
| repository: ' http://www.squeaksource.com/Seaside30 ';
| load.
|
| will auto-load Metacello and then load Seaside30.
|
|
| Hi Dale. Thanks for this, it is really needed. Esteban works on
| ProjectLoader was appreciated. But if this is provided out of the
| box with Metacello, then even better.
| I have many question regarding "defaults".
|
| 1) Am I able to also use #load: like i do to a version?

yes

| 2) #version: accepts also symbolic versions?

yes

| 3) if I don't specify the version, can we assume to use #stable?

... good idea

| 4) if I don't specify repository, can we assume that it is the
| associated one to the current Pharo version? (like the
| MetacelloBrowser does). For example, for Pharo 1.4 we have '
| http://www.squeaksource.com/MetaRepoForPharo14 ' for 2.0 '
| http://smalltalkhub.com/mc/Pharo/Packages20/main ', etc.
|

That is the plan ... I am torn between a single platform repository and a list of repositories with a look up order.

| So, if I just want the stable version, the associated repo, and the
| 'default' group then all I have to do is:
|
| Metacello new
| configuration: 'Seaside30';
| load.

yes

|
| 5) what happened to those that didn't follow the convention
| ConfigurationOf ? can you still do something like
| configurationNamed: 'XXXSeaside30' ?

  Metacello new
    project: 'Seaside30';
    className: 'XXXSeaside30';
    version: '3.0.7';
    repository: 'http://www.squeaksource.com/Seaside30';
    load.

| 6) Can we have shortcuts methods to well known repositories like ss,
| ss3, etc?

been considering that ...

| 7) if there will be some defaults, then I would really like that this
| is cleanly logged somewhere. Like
| - Downloading ConfiguraitonOfXXX from YYY repository.
| - Loading: group: 'default', version: zzz
| so that to know exactly what are you loading and from where.
|

Ah...recording the values of the defaults is a good idea.

There is a Metacello `registry` that is managed and you can query it to find out exactly what has been loaded ... In fact the registry is used to inform the loader as to what is loaded in the image (no more #currentVersion funkiness).

In addition to `load`, you will have `record` and `fetch` ... basically it should no longer be necessary to put your hands directly on the configuration to use it in a script.

|
| --
| Mariano
| http://marianopeck.wordpress.com

Dale

--
Mariano
http://marianopeck.wordpress.com

Thanks, man.

I've recorded your feedback in the issue list[1].

I encourage folks with additional feedback to open an issue on the issue list or make additional comments on existing issues ... or discuess here...feedback in all forms is welcome:)

Dale

[1] https://github.com/dalehenrich/metacello-work/issues

----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, June 13, 2012 8:08:23 AM
| Subject: Re: [Metacello] Metacell Base preview
|
|
|
|
| On Wed, Jun 13, 2012 at 5:00 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Mariano,
|
| Thanks for taking the time...good questions..
|
|
|
| thanks for providing this :)
|
|
|
| That is the plan ... I am torn between a single platform repository
| and a list of repositories with a look up order.
|
|
|
|
| I think the one of a list of reporisoties and a lookup order scales
| more. Like for example, we can first search in the specific Pharo
| repo and if not found, search, for example, in MetacelloRepository.
|
|
| | 7) if there will be some defaults, then I would really like that
| | this
| | is cleanly logged somewhere. Like
| | - Downloading ConfiguraitonOfXXX from YYY repository.
| | - Loading: group: 'default', version: zzz
| | so that to know exactly what are you loading and from where.
| |
|
|
|
| Ah...recording the values of the defaults is a good idea.
|
| There is a Metacello `registry` that is managed and you can query it
| to find out exactly what has been loaded ... In fact the registry is
| used to inform the loader as to what is loaded in the image (no more
| #currentVersion funkiness).
|
|
| Excellent. Because if we start to have defaults, it should be clear
| to to user to see what has been taken for those "non-defined" items.
|
|
|
| In addition to `load`, you will have `record` and `fetch` ...
| basically it should no longer be necessary to put your hands
| directly on the configuration to use it in a script.
|
|
|
| excellent :)
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

Hi,


>> That is the plan ... I am torn between a single platform repository and a
>> list of repositories with a look up order.
>>
>
> I think the one of a list of reporisoties and a lookup order scales more.
> Like for example, we can first search in the specific Pharo repo and if not
> found, search, for example, in MetacelloRepository.

I think this will lead to a ton of confusion. A default value should
have a simple interpretation that proves useful. Otherwise, the
default is not that useful anymore and you will end up using the long
version just because of control need.

In this case, I would  suggest to only lookup in one platform
repository. This will enforce a discipline that is highly needed.

Cheers,
Doru


--
www.tudorgirba.com

"Every thing has its own flow"

Doru,

That makes a lot of sense ... there is a nice correspondence with #stable (the default version) that makes a good story:

  Metacello new
    configuration: 'Seaside30';
    load.

will load the version of 'Seaside30' that is appropriate for your platform, searching in the repository that is a appropriate for your platform ...

Dale

----- Original Message -----
| From: "Tudor Girba" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, June 14, 2012 12:53:47 AM
| Subject: Re: [Metacello] Metacell Base preview
|
| Hi,
|
|
| >> That is the plan ... I am torn between a single platform
| >> repository and a
| >> list of repositories with a look up order.
| >>
| >
| > I think the one of a list of reporisoties and a lookup order scales
| > more.
| > Like for example, we can first search in the specific Pharo repo
| > and if not
| > found, search, for example, in MetacelloRepository.
|
| I think this will lead to a ton of confusion. A default value should
| have a simple interpretation that proves useful. Otherwise, the
| default is not that useful anymore and you will end up using the long
| version just because of control need.
|
| In this case, I would  suggest to only lookup in one platform
| repository. This will enforce a discipline that is highly needed.
|
| Cheers,
| Doru
|
|
| --
| www.tudorgirba.com
|
| "Every thing has its own flow"
|

Tudor Girba-2 wrote

In this case, I would  suggest to only lookup in one platform
repository. This will enforce a discipline that is highly needed.

Hmm, I'm not sold either way. It seems like that might be overly strict...

Let's do a thought experiment... In the most common case, if I'm a user (and that's ultimately what this is really all about), would it be better for me to wait around for each dialect to approve each project (which I don't see us having the manpower to do effectively), or, if there is a config in sqs/MetacelloRepository, which has a stable version for my platform, to try that? If someone went to the trouble of declaring a stable version for, say Pharo 1.3, I'm thinking there's a good change it's gonna work. There could always be a flag, like Zinc's #systemPolicy, that makes it stricter for when one wants more control... maybe something like #certifiedOnly that only looks in the dialect's repo...

Sean

Sean,

We're only talking about the default lookup repository to be used when you _don't_ specify a repository in the script.

If you want to bypass the platform default (or don't want to wait for it to be certified) then you can explicitly specify the repository where the config will be found ...

In my mind the default version and repository are for developers who want to "take a project for a spin" and they just want the thing to load without having to learn about where to find the configuration and which version is appropriate.

Dale


----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, June 14, 2012 2:16:43 PM
| Subject: [Metacello] Re: Metacell Base preview
|
|
| Tudor Girba-2 wrote
| >
| > In this case, I would  suggest to only lookup in one platform
| > repository. This will enforce a discipline that is highly needed.
| >
|
| Hmm, I'm not sold either way. It seems like that might be overly
| strict...
|
| Let's do a thought experiment... In the most common case, if I'm a
| user (and
| that's ultimately what this is really all about), would it be better
| for me
| to wait around for each dialect to approve each project (which I
| don't see
| us having the manpower to do effectively), or, if there is a config
| in
| sqs/MetacelloRepository, which has a stable version for my platform,
| to try
| that? If someone went to the trouble of declaring a stable version
| for, say
| Pharo 1.3, I'm thinking there's a good change it's gonna work. There
| could
| always be a flag, like Zinc's #systemPolicy, that makes it stricter
| for when
| one wants more control... maybe something like #certifiedOnly that
| only
| looks in the dialect's repo...
|
| Sean
|
| --
| View this message in context:
| http://forum.world.st/Metacell-Base-preview-tp4634488p4634869.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

Dale Henrichs wrote

We're only talking about the default lookup repository to be used when you _don't_ specify a repository in the script.

"That is the plan ... I am torn between a single platform repository and a list of repositories with a look up order."

Opinions:
Mariano: "the one of a list of reporisoties and a lookup order scales more" (+1)
vs.
Doru: "I would  suggest to only lookup in one platform repository"

Dale Henrichs wrote

In my mind the default version and repository are for developers who want to "take a project for a spin" and they just want the thing to load without having to learn about where to find the configuration and which version is appropriate.

Yes, that's my point exactly! If someone finds the project and wants it to "just load", we should automatically look in all the likely places in order of preference. Otherwise, if we fail after looking in one place (like the platform repo, where I envision most projects won't be), we force the casual user to understand the Metacello world and begin trying various locations (in the preferred order... preferably...). Oh, "not found in repo for 1.4...", where do I look next... google... okay, sqs/MetacelloRepository... nope... hmm... post to mailing list...

Ah ... "I reserve the right to change my mind before releasing a feature:)"

It turns out you and I have had this conversation before[1].

The `find` command is "my current answer" to the search path problem ... with the `find` command we can afford to cast a larger net for hunting down the project, looking in all of the usual locations with the ability for each dialect to insert a custom search path component ... the developer will be able to customize the path as well...

For _defaults_ I like Doru's opinion.

Up until this little discussion started, I had "made up my mind" to have no defaults in the scripting api.

Early on I did some work where I had a complicated list of search paths that were used to by the configurations themselves ... yes overriding the locations in project specs ... my rationale was if you want to use Seaside configuration from MySpecialRepository, then I don't want the Seaside configuration from any other repository to pollute my load ... besides just being complicated, search paths are guaranteed to be slow (how many times do you want to wait for SqueakSource to answer ... if it is up ... before Metacello _starts_ your request?)...

Since then I tossed out all thoughts of the search path until our conversation[2] a month ago when I agreed to basically the same argument you are making now and wrote the following in the issue:

  The find command is the gateway to the "configuration search path".

My answer to the hypothetical "I don't want the Seaside configuration from any other repository to pollute my load" is the `scripting api project registry`. The registry is explicitly managed, so you have fine grained control over exactly which version of a project and which configuration of the project is used and that combo is used whenever the project is loaded (including other projects). The the version and repository location is managed by configuration class name, so the actual contents of the registry isn't that complicated ...

So my "straw man" is:

  - default version is #stable
  - default repository for configuration look up is set by platform
  - `find` command is the gateway to the project search path

Hopefully, the `find` command addresses your (valid and important) concerns about folks being able to find a particular project.

Dale

[1] https://github.com/dalehenrich/metacello-work/issues/15
[2] http://forum.world.st/Minimal-base-image-Metacello-presence-for-GemStone-Pharo-and-Squeak-td4334269.html#a4630926

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, June 14, 2012 3:40:46 PM
| Subject: [Metacello] Re: Metacell Base preview
|
|
| Dale Henrichs wrote
| >
| > We're only talking about the default lookup repository to be used
| > when you
| > _don't_ specify a repository in the script.
| >
|
| "That is the plan ... I am torn between a single platform repository
| and a
| list of repositories with a look up order."
|
| Opinions:
| Mariano: "the one of a list of reporisoties and a lookup order scales
| more"
| (+1)
| vs.
| Doru: "I would  suggest to only lookup in one platform repository"
|
|
| Dale Henrichs wrote
| >
| > In my mind the default version and repository are for developers
| > who want
| > to "take a project for a spin" and they just want the thing to load
| > without having to learn about where to find the configuration and
| > which
| > version is appropriate.
| >
| Yes, that's my point exactly! If someone finds the project and wants
| it to
| "just load", we should automatically look in all the likely places in
| order
| of preference. Otherwise, if we fail after looking in one place (like
| the
| platform repo, where I envision most projects won't be), we force the
| casual
| user to understand the Metacello world and begin trying various
| locations
| (in the preferred order... preferably...). Oh, "not found in repo for
| 1.4...", where do I look next... google... okay,
| sqs/MetacelloRepository...
| nope... hmm... post to mailing list...
|
| --
| View this message in context:
| http://forum.world.st/Metacell-Base-preview-tp4634488p4634879.html
| Sent from the Metacello mailing list archive at Nabble.com.
|

I'm not sure if we're disagreeing or not :)

Would you give a quick example of "default" vs. find?

The use case I'm thinking of is: I am a naive user and I hear about a project, so I evaluate X (because I've seen lots of snippets like that, or have one from another project that I can copy/paste)...

And I'm hoping that it will check in more places, rather than less...

--
Mariano
http://marianopeck.wordpress.com

Sean,

The defaults are going to be used for a load:

  Metacello new
    configuration: 'Seaside30';
    load.

The default version will be #stable and the default repository will be platform-dependent.

In practice there will be well-known projects for which the above short hand will work very well. There will be other projects where one will have to supply a repository and still others for which #stable versions have yet to be defined.

For the defaults to _work_ for the naive user, we have to be 100% certain that a #stable version exists for the project if it is found in the platform-dependent repository. The only way to guarantee that is to qualify configurations for inclusion in the platform-dependent repository.

If no ConfigurationOfSeaside30, the error message should direct the user to use the `find` command...it might make sense for the `find` command to select configurations that have #stable versions defined for your platform ... I haven't completely fleshed out the `find` command yet ... but it seems clear to me that the `find` command is a better place to put an arbitrary search path than the `load/fetch/recored` commands...qualifiers like `has stable version` or `squeak and gemstone support` make sense as well ... don't ask me how these will be efficiently implemented:)

Let's keep thrashing on this until we get on the same page ...

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Thursday, June 14, 2012 5:16:01 PM
| Subject: [Metacello] Re: Metacell Base preview
|
| I'm not sure if we're disagreeing or not :)
|
| Would you give a quick example of "default" vs. find?
|
| The use case I'm thinking of is: I am a naive user and I hear about a
| project, so I evaluate X (because I've seen lots of snippets like
| that, or have one from another project that I can copy/paste)...
|
| And I'm hoping that it will check in more places, rather than less...
|
| View this message in context: Re: Metacell Base preview
| Sent from the Metacello mailing list archive at Nabble.com.
|

Mariano,

Given the limited range of defaults, I assume that the minimum qualifications for a project to be qualified for inclusion in the platform-specific repository are:

  - #stable version defined for the platform
  - #stable version loads without error into the platform image
  - all unit tests pass after load

So then we are down to only having to throw an error message if the configuration cannot be found which could be atypo or the project doesn't have a configuration for that platform ... in this case the user would be directed to the `find` command.

Of course, if a configuration sneaks in that does not have a #stable version, then the version not found error should be thrown, but the qualification process should filter those out...

Dale

----- Original Message -----
| From: "Mariano Martinez Peck" <[hidden email]>
| To: [hidden email]
| Sent: Friday, June 15, 2012 12:54:03 AM
| Subject: Re: [Metacello] Metacell Base preview
|
|
|
|
| On Thu, Jun 14, 2012 at 5:51 PM, Dale Henrichs < [hidden email]
| > wrote:
|
|
| Doru,
|
| That makes a lot of sense ... there is a nice correspondence with
| #stable (the default version) that makes a good story:
|
|
| Metacello new
| configuration: 'Seaside30';
| load.
|
| will load the version of 'Seaside30' that is appropriate for your
| platform, searching in the repository that is a appropriate for your
| platform ...
|
|
|
| I agree with Doru concern. However, I am not completly sure. If you
| didn't say a version, then you will search stable. If you say a
| version XX it is the same, in either case, you will search a
| specific version. Whether it is found in repo YY o ZZ should not
| matter. If they DO have version XX or stable, then they should be
| correct, right? otherwise you will just raise an error saying that
| that version was not found.
|
|
|
| Dale
|
|
| ----- Original Message -----
| | From: "Tudor Girba" < [hidden email] >
| | To: [hidden email]
| | Sent: Thursday, June 14, 2012 12:53:47 AM
| | Subject: Re: [Metacello] Metacell Base preview
| |
|
|
| | Hi,
| |
| |
| | >> That is the plan ... I am torn between a single platform
| | >> repository and a
| | >> list of repositories with a look up order.
| | >>
| | >
| | > I think the one of a list of reporisoties and a lookup order
| | > scales
| | > more.
| | > Like for example, we can first search in the specific Pharo repo
| | > and if not
| | > found, search, for example, in MetacelloRepository.
| |
| | I think this will lead to a ton of confusion. A default value
| | should
| | have a simple interpretation that proves useful. Otherwise, the
| | default is not that useful anymore and you will end up using the
| | long
| | version just because of control need.
| |
| | In this case, I would suggest to only lookup in one platform
| | repository. This will enforce a discipline that is highly needed.
| |
| | Cheers,
| | Doru
| |
| |
| | --
| | www.tudorgirba.com
| |
| | "Every thing has its own flow"
| |
|
|
|
| --
| Mariano
| http://marianopeck.wordpress.com
|
|

Dale Henrichs wrote

The default version will be #stable and the default repository will be platform-dependent... In practice there will be well-known projects for which the above short hand will work very well.

Okay, yes we are disagreeing :) Since we're restricting ourselves to #stable versions, I agree with Mariano: what difference does it make where we found the config? Someone took the time to declare a stable version, and I think it's better to try and load it rather than have a whole other step. If there's no stable version found, then by all means, have a second "well... you could try..." step.

The part about "well-known projects" is right on. I'm guessing there will be configs in the platform repo for a handful of projects like OB, Seaside, etc; but the vast majority of projects will not be there - there just doesn't seem to be enough manpower to have Squeak/Pharo/Gemstone check and approve each config (how many of the 100+ configs on http://www.squeaksource.com/MetacelloRepository alone can realistically be checked).

What is the downside to having load use a search path? It makes it more likely that a naive user will be successful and power users can always have a mechanism to have more control (e.g. #certifiedOnly)...