Metacello scripting: project lookup options and control

I'm thinking that the repository lookup list not be implemented a simple array of repositories, but as a segmented list with the following components (in lookup order):

  platform override repositories - user definable
  platform repositories          - defined by platform developers
  personal repositories          - user definable


The point of this post is to get reactions to the notion of a segmented list. When I have used GoferProjectLoader in the past, there were times when I wanted use a different repository list than the default and scripting schemes that involve ensure blocks in the script doesn't seem right. So I'm thinking along the following lines...

There are default values for each of lookup components at the system level, but when executing a script, the components can be individually enabled and/or overridden.

To define defaults, one uses class-side expressions like the following:

  Metacello
    platformOverrides: #('/opt/monticello/MyPlatformConfigs');
    personal: #('/opt/monticello/MyProjects').

I'm certain that class-side methods are pretty safe, but I am interested in your thoughts on the instance-side override/control mechanism.

Let's assume that '/opt/monticello/MyPlatformConfigs' has a private version of the ConfigurationOfSeaside30 and '/opt/monticello/MyProjects' has ConfigurationOfMYProject. Let's further assume that MyProject depends upon Seaside30.

The following script:

  Metacello new
    project: 'Seaside30';
    load.

will use the private version of ConfigurationOfSeaside30, while the following:

  Metacello new
    platformOverrides: #();
    project: 'Seaside30';
    load.

will use the ConfigurationOfSeaside30 from the platform-specific repository ('http://www.squeaksource.com/MetacelloRepository') and the following:

  Metacello new
    platformOverrides: #();
    disablePlatformRepositories;
    project: 'Seaside30';
    load.

will use the ConfigurationOfSeaside30 from the repository in the package-spec 'http://www.squeaksource.com/Seaside30'.

In my original post I had the following script:

  Metacello new
    project: 'Seaside30';
    signature: 'dkh.375';
    get.

In my mind, I wanted to be able to use a specific version of a configuration in the script, but I think that by providing #platformOverrides: a developer would be able to 'pin' a configuration to a specific version by simply copying ConfigurationOfSeaside30-dkh.375 to the platformOverrides: repository, a better solution to that problem, especially when coupled with the 'shared repository lookup'.

Dale

Being able to specify the repository outside the configuration is a good move.
Maybe in a configuration object or something.

Alexandre


On 8 Feb 2012, at 17:03, Dale Henrichs wrote:

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

Alexandre,

So you are thinking of an explicit map of 'project name' -> 'repository' instead of the less specific 'list of repositories'....

So in lookup order we'd have:

  repository map                 - dictionary of 'project name', 'repository' pairs

in addition to:

  platform override repositories - user definable
  platform repositories          - defined by platform developers
  personal repositories          - user definable

The we'd have system defaults with the option to override in script?

  Metacello
    mapRepository: ('Seaside30' -> '/opt/monticello/MySeasideRepo').

Dale

----- Original Message -----
| From: "Alexandre Bergel" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, February 8, 2012 12:21:29 PM
| Subject: Re: [Metacello] Metacello scripting: project lookup options and control
|
| Being able to specify the repository outside the configuration is a
| good move.
| Maybe in a configuration object or something.
|
| Alexandre
|
|
| On 8 Feb 2012, at 17:03, Dale Henrichs wrote:
|
| > I'm thinking that the repository lookup list not be implemented a
| > simple array of repositories, but as a segmented list with the
| > following components (in lookup order):
| >
| >  platform override repositories - user definable
| >  platform repositories          - defined by platform developers
| >  personal repositories          - user definable
| >
| >
| > The point of this post is to get reactions to the notion of a
| > segmented list. When I have used GoferProjectLoader in the past,
| > there were times when I wanted use a different repository list
| > than the default and scripting schemes that involve ensure blocks
| > in the script doesn't seem right. So I'm thinking along the
| > following lines...
| >
| > There are default values for each of lookup components at the
| > system level, but when executing a script, the components can be
| > individually enabled and/or overridden.
| >
| > To define defaults, one uses class-side expressions like the
| > following:
| >
| >  Metacello
| >    platformOverrides: #('/opt/monticello/MyPlatformConfigs');
| >    personal: #('/opt/monticello/MyProjects').
| >
| > I'm certain that class-side methods are pretty safe, but I am
| > interested in your thoughts on the instance-side override/control
| > mechanism.
| >
| > Let's assume that '/opt/monticello/MyPlatformConfigs' has a private
| > version of the ConfigurationOfSeaside30 and
| > '/opt/monticello/MyProjects' has ConfigurationOfMYProject. Let's
| > further assume that MyProject depends upon Seaside30.
| >
| > The following script:
| >
| >  Metacello new
| >    project: 'Seaside30';
| >    load.
| >
| > will use the private version of ConfigurationOfSeaside30, while the
| > following:
| >
| >  Metacello new
| >    platformOverrides: #();
| >    project: 'Seaside30';
| >    load.
| >
| > will use the ConfigurationOfSeaside30 from the platform-specific
| > repository ('http://www.squeaksource.com/MetacelloRepository') and
| > the following:
| >
| >  Metacello new
| >    platformOverrides: #();
| >    disablePlatformRepositories;
| >    project: 'Seaside30';
| >    load.
| >
| > will use the ConfigurationOfSeaside30 from the repository in the
| > package-spec 'http://www.squeaksource.com/Seaside30'.
| >
| > In my original post I had the following script:
| >
| >  Metacello new
| >    project: 'Seaside30';
| >    signature: 'dkh.375';
| >    get.
| >
| > In my mind, I wanted to be able to use a specific version of a
| > configuration in the script, but I think that by providing
| > #platformOverrides: a developer would be able to 'pin' a
| > configuration to a specific version by simply copying
| > ConfigurationOfSeaside30-dkh.375 to the platformOverrides:
| > repository, a better solution to that problem, especially when
| > coupled with the 'shared repository lookup'.
| >
| > Dale
|
| --
| _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
| Alexandre Bergel  http://www.bergel.eu
| ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
|
|
|
|
|

Yes, something like this.
On some point, I will migrate from squeaksource.com to ss3.gemstone.com. It will be cool if I do not have to manually update all the baselines.
Another case study, is to use the local cache or the chilean mirror instead of the remote repository.

Cheers,
Alexandre


On 8 Feb 2012, at 18:15, Dale Henrichs wrote:

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

Alexandre,

Okay, I understand better ...

As far as updating baselines, I would think that you only need to modify the baseline for your current development versions ... The project will still exist on SqueakSource and will still be reachable via the mirror if SqueakSource is down...

So in the end I would say that you don't NEED to modify them, but you certainly could modify them:)

Dale

----- Original Message -----
| From: "Alexandre Bergel" <[hidden email]>
| To: [hidden email]
| Sent: Wednesday, February 8, 2012 2:33:36 PM
| Subject: Re: [Metacello] Metacello scripting: project lookup options and control
|
| Yes, something like this.
| On some point, I will migrate from squeaksource.com to
| ss3.gemstone.com. It will be cool if I do not have to manually
| update all the baselines.
| Another case study, is to use the local cache or the chilean mirror
| instead of the remote repository.
|
| Cheers,
| Alexandre
|
|
| On 8 Feb 2012, at 18:15, Dale Henrichs wrote:
|
| > Alexandre,
| >
| > So you are thinking of an explicit map of 'project name' ->
| > 'repository' instead of the less specific 'list of
| > repositories'....
| >
| > So in lookup order we'd have:
| >
| >  repository map                 - dictionary of 'project name',
| >  'repository' pairs
| >
| > in addition to:
| >
| >  platform override repositories - user definable
| >  platform repositories          - defined by platform developers
| >  personal repositories          - user definable
| >
| > The we'd have system defaults with the option to override in
| > script?
| >
| >  Metacello
| >    mapRepository: ('Seaside30' -> '/opt/monticello/MySeasideRepo').
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Alexandre Bergel" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Wednesday, February 8, 2012 12:21:29 PM
| > | Subject: Re: [Metacello] Metacello scripting: project lookup
| > | options and control
| > |
| > | Being able to specify the repository outside the configuration is
| > | a
| > | good move.
| > | Maybe in a configuration object or something.
| > |
| > | Alexandre
| > |
| > |
| > | On 8 Feb 2012, at 17:03, Dale Henrichs wrote:
| > |
| > | > I'm thinking that the repository lookup list not be implemented
| > | > a
| > | > simple array of repositories, but as a segmented list with the
| > | > following components (in lookup order):
| > | >
| > | >  platform override repositories - user definable
| > | >  platform repositories          - defined by platform
| > | >  developers
| > | >  personal repositories          - user definable
| > | >
| > | >
| > | > The point of this post is to get reactions to the notion of a
| > | > segmented list. When I have used GoferProjectLoader in the
| > | > past,
| > | > there were times when I wanted use a different repository list
| > | > than the default and scripting schemes that involve ensure
| > | > blocks
| > | > in the script doesn't seem right. So I'm thinking along the
| > | > following lines...
| > | >
| > | > There are default values for each of lookup components at the
| > | > system level, but when executing a script, the components can
| > | > be
| > | > individually enabled and/or overridden.
| > | >
| > | > To define defaults, one uses class-side expressions like the
| > | > following:
| > | >
| > | >  Metacello
| > | >    platformOverrides: #('/opt/monticello/MyPlatformConfigs');
| > | >    personal: #('/opt/monticello/MyProjects').
| > | >
| > | > I'm certain that class-side methods are pretty safe, but I am
| > | > interested in your thoughts on the instance-side
| > | > override/control
| > | > mechanism.
| > | >
| > | > Let's assume that '/opt/monticello/MyPlatformConfigs' has a
| > | > private
| > | > version of the ConfigurationOfSeaside30 and
| > | > '/opt/monticello/MyProjects' has ConfigurationOfMYProject.
| > | > Let's
| > | > further assume that MyProject depends upon Seaside30.
| > | >
| > | > The following script:
| > | >
| > | >  Metacello new
| > | >    project: 'Seaside30';
| > | >    load.
| > | >
| > | > will use the private version of ConfigurationOfSeaside30, while
| > | > the
| > | > following:
| > | >
| > | >  Metacello new
| > | >    platformOverrides: #();
| > | >    project: 'Seaside30';
| > | >    load.
| > | >
| > | > will use the ConfigurationOfSeaside30 from the
| > | > platform-specific
| > | > repository ('http://www.squeaksource.com/MetacelloRepository')
| > | > and
| > | > the following:
| > | >
| > | >  Metacello new
| > | >    platformOverrides: #();
| > | >    disablePlatformRepositories;
| > | >    project: 'Seaside30';
| > | >    load.
| > | >
| > | > will use the ConfigurationOfSeaside30 from the repository in
| > | > the
| > | > package-spec 'http://www.squeaksource.com/Seaside30'.
| > | >
| > | > In my original post I had the following script:
| > | >
| > | >  Metacello new
| > | >    project: 'Seaside30';
| > | >    signature: 'dkh.375';
| > | >    get.
| > | >
| > | > In my mind, I wanted to be able to use a specific version of a
| > | > configuration in the script, but I think that by providing
| > | > #platformOverrides: a developer would be able to 'pin' a
| > | > configuration to a specific version by simply copying
| > | > ConfigurationOfSeaside30-dkh.375 to the platformOverrides:
| > | > repository, a better solution to that problem, especially when
| > | > coupled with the 'shared repository lookup'.
| > | >
| > | > Dale
| > |
| > | --
| > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
| > | Alexandre Bergel  http://www.bergel.eu
| > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
| > |
| > |
| > |
| > |
| > |
| > |
|
| --
| _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
| Alexandre Bergel  http://www.bergel.eu
| ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
|
|
|
|
|

Norbert and Alexandre,

I would like your opinion on my plan to address this issue via the Metacello scripting API. Specifically, you can include a list of default repositories that are used to resolve all configuration lookups:

  Metacello
    platformOverrides: #('/opt/monticello/MyPlatformConfigs');
    "platform-specific MetacelloRepositories"
    personal: #('/opt/monticello/MyProjects').

On a script by script basis, you can override the defaults:

  Metacello new
    platformOverrides: #('/opt/monticello/PinnedConfigurations').
    project: 'Seaside30';
    load.

So instead of having to specify a lookup repository for each project, you can simply copy the configurations that you explicitly want to use into one of your local repositories.

I'm asking because what you two appear to be asking for is something like the following:

  Metacello
    project: 'Seaside30' defaultRepositories: #('/opt/monticello/MyPlatformConfigs').

but I think that in practice both forms are basically equivalent, but there are subtle differences between the two forms, so I'm curious about the details of your use cases...

In regards to the credentials for the repositories, I don't have a good solution ... I suppose if you had a separate secret script that you ran to create all of the credentialled repositories in your image, then Metacello would just use them and wouldn't have to create them first ...

Dale

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: [hidden email]
| Sent: Friday, February 10, 2012 9:37:05 AM
| Subject: Re: [Metacello] Metacello scripting: project lookup options and control
|
|
|
|
| Am 08.02.2012 um 21:21 schrieb Alexandre Bergel:
|
|
|
| Being able to specify the repository outside the configuration is a
| good move.
| Maybe in a configuration object or something.
|
| I like this idea. Although being discussable I hate it to put
| username/password information in a configuration. I would prefer
| taking the extra effort to specify a repository outside to
| configuration and inject it.
|
|
| Norbert
|
|
|
|
|
| On 8 Feb 2012, at 17:03, Dale Henrichs wrote:
|
|
|
| I'm thinking that the repository lookup list not be implemented a
| simple array of repositories, but as a segmented list with the
| following components (in lookup order):
|
|
|
|
|
| platform override repositories - user definable
|
|
| platform repositories - defined by platform developers
|
|
| personal repositories - user definable
|
|
|
|
|
|
|
|
| The point of this post is to get reactions to the notion of a
| segmented list. When I have used GoferProjectLoader in the past,
| there were times when I wanted use a different repository list than
| the default and scripting schemes that involve ensure blocks in the
| script doesn't seem right. So I'm thinking along the following
| lines...
|
|
|
|
|
| There are default values for each of lookup components at the system
| level, but when executing a script, the components can be
| individually enabled and/or overridden.
|
|
|
|
|
| To define defaults, one uses class-side expressions like the
| following:
|
|
|
|
|
| Metacello
|
|
| platformOverrides: #('/opt/monticello/MyPlatformConfigs');
|
|
| personal: #('/opt/monticello/MyProjects').
|
|
|
|
|
| I'm certain that class-side methods are pretty safe, but I am
| interested in your thoughts on the instance-side override/control
| mechanism.
|
|
|
|
|
| Let's assume that '/opt/monticello/MyPlatformConfigs' has a private
| version of the ConfigurationOfSeaside30 and
| '/opt/monticello/MyProjects' has ConfigurationOfMYProject. Let's
| further assume that MyProject depends upon Seaside30.
|
|
|
|
|
| The following script:
|
|
|
|
|
| Metacello new
|
|
| project: 'Seaside30';
|
|
| load.
|
|
|
|
|
| will use the private version of ConfigurationOfSeaside30, while the
| following:
|
|
|
|
|
| Metacello new
|
|
| platformOverrides: #();
|
|
| project: 'Seaside30';
|
|
| load.
|
|
|
|
|
| will use the ConfigurationOfSeaside30 from the platform-specific
| repository (' http://www.squeaksource.com/MetacelloRepository' ) and
| the following:
|
|
|
|
|
| Metacello new
|
|
| platformOverrides: #();
|
|
| disablePlatformRepositories;
|
|
| project: 'Seaside30';
|
|
| load.
|
|
|
|
|
| will use the ConfigurationOfSeaside30 from the repository in the
| package-spec ' http://www.squeaksource.com/Seaside30' .
|
|
|
|
|
| In my original post I had the following script:
|
|
|
|
|
| Metacello new
|
|
| project: 'Seaside30';
|
|
| signature: 'dkh.375';
|
|
| get.
|
|
|
|
|
| In my mind, I wanted to be able to use a specific version of a
| configuration in the script, but I think that by providing
| #platformOverrides: a developer would be able to 'pin' a
| configuration to a specific version by simply copying
| ConfigurationOfSeaside30-dkh.375 to the platformOverrides:
| repository, a better solution to that problem, especially when
| coupled with the 'shared repository lookup'.
|
|
|
|
|
| Dale
|
| --
| _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
| Alexandre Bergel http://www.bergel.eu
| ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
|
|
|
|
|
|
|

Dale,

I was thinking a few days about it but I fear I have less to add. The management of secrets just came to my mind. For everything else I rely at the moment on  plain configurations that pull everything from online. I started to play with local repositories but still did not get how I should be doing it best for my use cases. I think the local repositories are important but it's not clear how the local repositories are managed best. Is it only copying a specific version of a configuration or treat the packages in a similar way.
What I use is overrides of all flavours. Sometimes I need a newer package (e.g. the seaside-email package had a fix two versions later). Then there are fixes I did myself (like the fastcgi). For this I use patch packages to load explicitly at the end of metacello. Then there are packages that I only want to patch (xml parser writeXMLOn: confusion) which I do by applying method overrides with own packages.
You see there are issues but no plan how to arrange things properly and reliable.

Sorry for not being that much helpful,

Norbert

Am 10.02.2012 um 18:55 schrieb Dale Henrichs:

I don't know if it's entirely germane, but the usual maven way is to
have a local settings.xml file containing credentials, outside one's
repository.

If Metacello could read a configuration file associating credentials
with repositories, that would work.

frank

On 13 February 2012 21:25, Norbert Hartl <[hidden email]> wrote:

Frank,

I just looked at Pharo 1.3 and I noticed the following:

  MCHttpRepository>>userAndPasswordFromSettingsDo:

which looks like it is doing something along the lines you have suggested and as I think about, I'd almost prefer to rely on a platform-specific mechanism for dealing with the secrets, than invent one that might be incompatible with the standard platform mechanism ...

For credentials, I might just punt for the short term...

Dale

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 13, 2012 1:34:15 PM
| Subject: Re: [Metacello] Metacello scripting: project lookup options and control
|
| I don't know if it's entirely germane, but the usual maven way is to
| have a local settings.xml file containing credentials, outside one's
| repository.
|
| If Metacello could read a configuration file associating credentials
| with repositories, that would work.
|
| frank
|
| On 13 February 2012 21:25, Norbert Hartl <[hidden email]> wrote:
| > Dale,
| >
| > I was thinking a few days about it but I fear I have less to add.
| > The management of secrets just came to my mind. For everything
| > else I rely at the moment on  plain configurations that pull
| > everything from online. I started to play with local repositories
| > but still did not get how I should be doing it best for my use
| > cases. I think the local repositories are important but it's not
| > clear how the local repositories are managed best. Is it only
| > copying a specific version of a configuration or treat the
| > packages in a similar way.
| > What I use is overrides of all flavours. Sometimes I need a newer
| > package (e.g. the seaside-email package had a fix two versions
| > later). Then there are fixes I did myself (like the fastcgi). For
| > this I use patch packages to load explicitly at the end of
| > metacello. Then there are packages that I only want to patch (xml
| > parser writeXMLOn: confusion) which I do by applying method
| > overrides with own packages.
| > You see there are issues but no plan how to arrange things properly
| > and reliable.
| >
| > Sorry for not being that much helpful,
| >
| > Norbert
| >
| > Am 10.02.2012 um 18:55 schrieb Dale Henrichs:
| >
| >> Norbert and Alexandre,
| >>
| >> I would like your opinion on my plan to address this issue via the
| >> Metacello scripting API. Specifically, you can include a list of
| >> default repositories that are used to resolve all configuration
| >> lookups:
| >>
| >>  Metacello
| >>    platformOverrides: #('/opt/monticello/MyPlatformConfigs');
| >>    "platform-specific MetacelloRepositories"
| >>    personal: #('/opt/monticello/MyProjects').
| >>
| >> On a script by script basis, you can override the defaults:
| >>
| >>  Metacello new
| >>    platformOverrides: #('/opt/monticello/PinnedConfigurations').
| >>    project: 'Seaside30';
| >>    load.
| >>
| >> So instead of having to specify a lookup repository for each
| >> project, you can simply copy the configurations that you
| >> explicitly want to use into one of your local repositories.
| >>
| >> I'm asking because what you two appear to be asking for is
| >> something like the following:
| >>
| >>  Metacello
| >>    project: 'Seaside30' defaultRepositories:
| >>    #('/opt/monticello/MyPlatformConfigs').
| >>
| >> but I think that in practice both forms are basically equivalent,
| >> but there are subtle differences between the two forms, so I'm
| >> curious about the details of your use cases...
| >>
| >> In regards to the credentials for the repositories, I don't have a
| >> good solution ... I suppose if you had a separate secret script
| >> that you ran to create all of the credentialled repositories in
| >> your image, then Metacello would just use them and wouldn't have
| >> to create them first ...
| >>
| >> Dale
| >>
| >> ----- Original Message -----
| >> | From: "Norbert Hartl" <[hidden email]>
| >> | To: [hidden email]
| >> | Sent: Friday, February 10, 2012 9:37:05 AM
| >> | Subject: Re: [Metacello] Metacello scripting: project lookup
| >> | options and control
| >> |
| >> |
| >> |
| >> |
| >> | Am 08.02.2012 um 21:21 schrieb Alexandre Bergel:
| >> |
| >> |
| >> |
| >> | Being able to specify the repository outside the configuration
| >> | is a
| >> | good move.
| >> | Maybe in a configuration object or something.
| >> |
| >> | I like this idea. Although being discussable I hate it to put
| >> | username/password information in a configuration. I would prefer
| >> | taking the extra effort to specify a repository outside to
| >> | configuration and inject it.
| >> |
| >> |
| >> | Norbert
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | On 8 Feb 2012, at 17:03, Dale Henrichs wrote:
| >> |
| >> |
| >> |
| >> | I'm thinking that the repository lookup list not be implemented
| >> | a
| >> | simple array of repositories, but as a segmented list with the
| >> | following components (in lookup order):
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | platform override repositories - user definable
| >> |
| >> |
| >> | platform repositories - defined by platform developers
| >> |
| >> |
| >> | personal repositories - user definable
| >> |
| >> |
| >> |
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | The point of this post is to get reactions to the notion of a
| >> | segmented list. When I have used GoferProjectLoader in the past,
| >> | there were times when I wanted use a different repository list
| >> | than
| >> | the default and scripting schemes that involve ensure blocks in
| >> | the
| >> | script doesn't seem right. So I'm thinking along the following
| >> | lines...
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | There are default values for each of lookup components at the
| >> | system
| >> | level, but when executing a script, the components can be
| >> | individually enabled and/or overridden.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | To define defaults, one uses class-side expressions like the
| >> | following:
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | Metacello
| >> |
| >> |
| >> | platformOverrides: #('/opt/monticello/MyPlatformConfigs');
| >> |
| >> |
| >> | personal: #('/opt/monticello/MyProjects').
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | I'm certain that class-side methods are pretty safe, but I am
| >> | interested in your thoughts on the instance-side
| >> | override/control
| >> | mechanism.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | Let's assume that '/opt/monticello/MyPlatformConfigs' has a
| >> | private
| >> | version of the ConfigurationOfSeaside30 and
| >> | '/opt/monticello/MyProjects' has ConfigurationOfMYProject. Let's
| >> | further assume that MyProject depends upon Seaside30.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | The following script:
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | Metacello new
| >> |
| >> |
| >> | project: 'Seaside30';
| >> |
| >> |
| >> | load.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | will use the private version of ConfigurationOfSeaside30, while
| >> | the
| >> | following:
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | Metacello new
| >> |
| >> |
| >> | platformOverrides: #();
| >> |
| >> |
| >> | project: 'Seaside30';
| >> |
| >> |
| >> | load.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | will use the ConfigurationOfSeaside30 from the platform-specific
| >> | repository (' http://www.squeaksource.com/MetacelloRepository' )
| >> | and
| >> | the following:
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | Metacello new
| >> |
| >> |
| >> | platformOverrides: #();
| >> |
| >> |
| >> | disablePlatformRepositories;
| >> |
| >> |
| >> | project: 'Seaside30';
| >> |
| >> |
| >> | load.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | will use the ConfigurationOfSeaside30 from the repository in the
| >> | package-spec ' http://www.squeaksource.com/Seaside30' .
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | In my original post I had the following script:
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | Metacello new
| >> |
| >> |
| >> | project: 'Seaside30';
| >> |
| >> |
| >> | signature: 'dkh.375';
| >> |
| >> |
| >> | get.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | In my mind, I wanted to be able to use a specific version of a
| >> | configuration in the script, but I think that by providing
| >> | #platformOverrides: a developer would be able to 'pin' a
| >> | configuration to a specific version by simply copying
| >> | ConfigurationOfSeaside30-dkh.375 to the platformOverrides:
| >> | repository, a better solution to that problem, especially when
| >> | coupled with the 'shared repository lookup'.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> | Dale
| >> |
| >> | --
| >> | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
| >> | Alexandre Bergel http://www.bergel.eu
| >> | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
| >> |
| >> |
| >> |
| >> |
| >> |
| >> |
| >> |
| >
|

Norbert,

Do you agree that if you were able to use git that you might not need so many different mechanisms?

With git you could fork a project (or create a branch) rather than use the multitude of different mcz patch files.

You need to be able to point to your fork of the project and tell Metacello that you want to use your own fork of the project "no matter what".

My suggestion for repository lookup path is just the start. The lookup allows you to pin a configuration to the one you want to use.

As the next level of local control I am thinking that you'd want to explicitly specify exactly which version of a project to use, overriding any project references in the loaded dependent projects. If a project were to specify a different version Metacello would throw an error or a warning ...

Similar to the lookup path, you'd be able to specify default "project versions" at the system level and at the script level.

The simplest example would be:

  Metacello
    pin: 'Grease' version '1.0'.

The when you load Seaside30 (which depends upon Grease) with the following expression:

  Metacello new
    project: 'Seaside30' version: '3.0';
    load.

you'd get Grease 1.0 loaded, because Seaside 3.0 requires Grease 1.0.

However, in the following case, Seaside 3.0.6 requires Grease 1.0.6, but with Grease pinned to version 1.0, the following expression:

  Metacello new
    project: 'Seaside30' version: '3.0.6.3';
    load.

will load Seaside 3.0.6.3 and Grease 1.0.

Of course, pinning a specific version in this way has limited utility using Monticello repositories, but with directory-based repositories, one must be able to pin the "project version" to a particular location on disk so that all or you loads and builds will use the version of the project that is located at a spot on disk. for this case you'd use something like the following:

  Metacello
    pin: 'Grease' filetree: '/foos1/users/dhenrich/smalltalk/grease/'.

In practical terms, you will have cloned the github repository for Grease to your local disk in the directory '/foos1/users/dhenrich/smalltalk/grease/' and done a checkout of Grease 1.0.6 in your working directory where you are making your local changes to Grease. Of course, whenever you load a project that requires Grease, you'd like to force the system to load from the directory '/foos1/users/dhenrich/smalltalk/grease/' and not from the "standard location".

In this example I've just specified a local directory repository, but the contents of the directory could be indepently managed with git or even svn.

Then backing up to a Monticello example, you might start development on Grease 1.0.7 and you've saved the ConfigurationOfGrease along with the mcz file changes to the Grease Monticello repository and now you'd like to test projects that use Grease with your new version. In this case an expression like the following then makes sense:

  Metacello new
    pin: 'Grease' version '1.0.7';
    project: 'Seaside30' version: '3.0.6.3';
    load.

This would then allow you to specify that you'd like Grease 1.0.7 (your development version of Grease) be unconditionally loaded for Seaside 3.0.6.3 ... overriding any existing specifications.

Dale

----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: [hidden email]
| Sent: Monday, February 13, 2012 1:25:47 PM
| Subject: Re: [Metacello] Metacello scripting: project lookup options and control
|
| Dale,
|
| I was thinking a few days about it but I fear I have less to add. The
| management of secrets just came to my mind. For everything else I
| rely at the moment on  plain configurations that pull everything
| from online. I started to play with local repositories but still did
| not get how I should be doing it best for my use cases. I think the
| local repositories are important but it's not clear how the local
| repositories are managed best. Is it only copying a specific version
| of a configuration or treat the packages in a similar way.
| What I use is overrides of all flavours. Sometimes I need a newer
| package (e.g. the seaside-email package had a fix two versions
| later). Then there are fixes I did myself (like the fastcgi). For
| this I use patch packages to load explicitly at the end of
| metacello. Then there are packages that I only want to patch (xml
| parser writeXMLOn: confusion) which I do by applying method
| overrides with own packages.
| You see there are issues but no plan how to arrange things properly
| and reliable.
|
| Sorry for not being that much helpful,
|
| Norbert
|
| Am 10.02.2012 um 18:55 schrieb Dale Henrichs:
|
| > Norbert and Alexandre,
| >
| > I would like your opinion on my plan to address this issue via the
| > Metacello scripting API. Specifically, you can include a list of
| > default repositories that are used to resolve all configuration
| > lookups:
| >
| >  Metacello
| >    platformOverrides: #('/opt/monticello/MyPlatformConfigs');
| >    "platform-specific MetacelloRepositories"
| >    personal: #('/opt/monticello/MyProjects').
| >
| > On a script by script basis, you can override the defaults:
| >
| >  Metacello new
| >    platformOverrides: #('/opt/monticello/PinnedConfigurations').
| >    project: 'Seaside30';
| >    load.
| >
| > So instead of having to specify a lookup repository for each
| > project, you can simply copy the configurations that you
| > explicitly want to use into one of your local repositories.
| >
| > I'm asking because what you two appear to be asking for is
| > something like the following:
| >
| >  Metacello
| >    project: 'Seaside30' defaultRepositories:
| >    #('/opt/monticello/MyPlatformConfigs').
| >
| > but I think that in practice both forms are basically equivalent,
| > but there are subtle differences between the two forms, so I'm
| > curious about the details of your use cases...
| >
| > In regards to the credentials for the repositories, I don't have a
| > good solution ... I suppose if you had a separate secret script
| > that you ran to create all of the credentialled repositories in
| > your image, then Metacello would just use them and wouldn't have
| > to create them first ...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Norbert Hartl" <[hidden email]>
| > | To: [hidden email]
| > | Sent: Friday, February 10, 2012 9:37:05 AM
| > | Subject: Re: [Metacello] Metacello scripting: project lookup
| > | options and control
| > |
| > |
| > |
| > |
| > | Am 08.02.2012 um 21:21 schrieb Alexandre Bergel:
| > |
| > |
| > |
| > | Being able to specify the repository outside the configuration is
| > | a
| > | good move.
| > | Maybe in a configuration object or something.
| > |
| > | I like this idea. Although being discussable I hate it to put
| > | username/password information in a configuration. I would prefer
| > | taking the extra effort to specify a repository outside to
| > | configuration and inject it.
| > |
| > |
| > | Norbert
| > |
| > |
| > |
| > |
| > |
| > | On 8 Feb 2012, at 17:03, Dale Henrichs wrote:
| > |
| > |
| > |
| > | I'm thinking that the repository lookup list not be implemented a
| > | simple array of repositories, but as a segmented list with the
| > | following components (in lookup order):
| > |
| > |
| > |
| > |
| > |
| > | platform override repositories - user definable
| > |
| > |
| > | platform repositories - defined by platform developers
| > |
| > |
| > | personal repositories - user definable
| > |
| > |
| > |
| > |
| > |
| > |
| > |
| > |
| > | The point of this post is to get reactions to the notion of a
| > | segmented list. When I have used GoferProjectLoader in the past,
| > | there were times when I wanted use a different repository list
| > | than
| > | the default and scripting schemes that involve ensure blocks in
| > | the
| > | script doesn't seem right. So I'm thinking along the following
| > | lines...
| > |
| > |
| > |
| > |
| > |
| > | There are default values for each of lookup components at the
| > | system
| > | level, but when executing a script, the components can be
| > | individually enabled and/or overridden.
| > |
| > |
| > |
| > |
| > |
| > | To define defaults, one uses class-side expressions like the
| > | following:
| > |
| > |
| > |
| > |
| > |
| > | Metacello
| > |
| > |
| > | platformOverrides: #('/opt/monticello/MyPlatformConfigs');
| > |
| > |
| > | personal: #('/opt/monticello/MyProjects').
| > |
| > |
| > |
| > |
| > |
| > | I'm certain that class-side methods are pretty safe, but I am
| > | interested in your thoughts on the instance-side override/control
| > | mechanism.
| > |
| > |
| > |
| > |
| > |
| > | Let's assume that '/opt/monticello/MyPlatformConfigs' has a
| > | private
| > | version of the ConfigurationOfSeaside30 and
| > | '/opt/monticello/MyProjects' has ConfigurationOfMYProject. Let's
| > | further assume that MyProject depends upon Seaside30.
| > |
| > |
| > |
| > |
| > |
| > | The following script:
| > |
| > |
| > |
| > |
| > |
| > | Metacello new
| > |
| > |
| > | project: 'Seaside30';
| > |
| > |
| > | load.
| > |
| > |
| > |
| > |
| > |
| > | will use the private version of ConfigurationOfSeaside30, while
| > | the
| > | following:
| > |
| > |
| > |
| > |
| > |
| > | Metacello new
| > |
| > |
| > | platformOverrides: #();
| > |
| > |
| > | project: 'Seaside30';
| > |
| > |
| > | load.
| > |
| > |
| > |
| > |
| > |
| > | will use the ConfigurationOfSeaside30 from the platform-specific
| > | repository (' http://www.squeaksource.com/MetacelloRepository' )
| > | and
| > | the following:
| > |
| > |
| > |
| > |
| > |
| > | Metacello new
| > |
| > |
| > | platformOverrides: #();
| > |
| > |
| > | disablePlatformRepositories;
| > |
| > |
| > | project: 'Seaside30';
| > |
| > |
| > | load.
| > |
| > |
| > |
| > |
| > |
| > | will use the ConfigurationOfSeaside30 from the repository in the
| > | package-spec ' http://www.squeaksource.com/Seaside30' .
| > |
| > |
| > |
| > |
| > |
| > | In my original post I had the following script:
| > |
| > |
| > |
| > |
| > |
| > | Metacello new
| > |
| > |
| > | project: 'Seaside30';
| > |
| > |
| > | signature: 'dkh.375';
| > |
| > |
| > | get.
| > |
| > |
| > |
| > |
| > |
| > | In my mind, I wanted to be able to use a specific version of a
| > | configuration in the script, but I think that by providing
| > | #platformOverrides: a developer would be able to 'pin' a
| > | configuration to a specific version by simply copying
| > | ConfigurationOfSeaside30-dkh.375 to the platformOverrides:
| > | repository, a better solution to that problem, especially when
| > | coupled with the 'shared repository lookup'.
| > |
| > |
| > |
| > |
| > |
| > | Dale
| > |
| > | --
| > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
| > | Alexandre Bergel http://www.bergel.eu
| > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
| > |
| > |
| > |
| > |
| > |
| > |
| > |
|
|