Re: metacello diamond project dependency problem

Johan,

Sorry about the metacello group membership thing ... I had gotten a gmail account a while back and then I (unfortunately) joined g+ and then google insisted that the gmail account be used for logging in and then magically all of the notification mail that I had carefully configured to come to my vmware mailbox has been sent to my gmail account (which I never use) ... I'm not sure when this happened and I only noticed recently that I wasn't receiving mail that I expected to be getting (like metacello membership pending) ... I've cc'd the metacello list so we can continue the conversation there..

Two things:

  1. the fetching old versions of packages does happen ... they are not _loaded_ but they
     do get fetched ... this would be a tough nut to crack with the current version
     of Metacello
  2. I'm about to release (today or tomorrow) a pre-release version of Metacello that
     introduces a scripting API that is intended to allow you to "pin" projects to a
     particular version (without editting configs) and no fetching of packages from
     older versions will occur .... so you'd be the "perfect test case".

This pre-release version of Metacello should not have any behavior differences from the current released version of Metacello with the exception of the addition of git/github support (which you don't need) and the scripting api (which you do).

So if you are willing I'd like you to attempt to use the pre-release version of Metacello to get your job done ... I'm more than willing to commit to fixing bugs and tweak features so that you can get Metacello to work for you ...

I am suggesting that you use the pre-release because the intent of the features that I've added to the scripting api is to:

  be able to tell metacello to explicitly load a
  certain version of a project _regardless_ of what a dependent
  project's configuration has to say about that.

There are actually two features of the API that come into play:

  1. the project registry
  2. the ability to customize upgrades/downgrades

The project registry records the projectSpecs that you used when loading the image ... so the api knows exactly what you loaded. You can add a specification to the registry BEFORE the project is actually loaded so that when a project has that project as a dependency the version in the registry will be used. You can lock project registrations so that an error will be thrown if an attempt is made to load a different version of the specified project.

The customization comes into play when you hit a load expression that causes a lock error or that you know will do something you don't want...for every project upgrade/downgrade during a load, you have the opportunity `allow` or `disallow` the action. By default upgrades are allowed and downgrades are disallowed, but you can specify your own rules ...

In your case you will want to `lock` Seaside to a particular version and repository:

  Metacello new
    configuration: 'Seaside30';
    version: '3.0.7.1';
    repository: '<repository description for your override repository>';
    lock.

Then when you load Seaside-Testing you use the api to deny upgrades/downgrades for Seaside30 and bypass lock violation errors:

  Metacello new
    configuration: 'Seaside-Testing';
    version: #stable;
    repository: '<repositiory description for Seaside-Testing config>';
    onUpgrade: [:ex :existing :new |
      new baseName = 'Seaside30
        ifTrue: [ ex disallow ].
      ex pass];
    onDowngrade: [:ex :existing :new |
      new baseName = 'Seaside30
        ifTrue: [ ex disallow ].
      ex pass]      
    load.

Technically you can probably get by without the onUpgrade: onDowngrade: blocks in this case, because the pre-registration of Seaside30 should cause Seaside-Testing to use 3.0.7.1 instead of 3.0.0-rc.2...

So if you are willing to be a guinea pig, give me the particulars of the version of pharo that you are using (pharo-1.3 and pharo-1.4 are known to work ... pharo-2.0 has issues and I just haven't tried pharo-1.2 and earlier versions yet ... it also known to work on Squeak4.3, GemStone2.4 and GemStone3.1) and if you're using something other that 1.3 or 1.4 I'll ensure that the api works there.

So what do you think?

Dale

[1] http://code.google.com/p/metacello/issues/detail?id=150
----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Sent: Thursday, July 26, 2012 8:18:22 AM
| Subject: metacello diamond project dependency problem
|
| Hi Dale,
|
| I wanted to send this to the metacello group, but I do not have
| access (yet).
| Since I'm stuck with it, I thought to ask you directly already.
|
| I have a problem with diamond project dependencies in metacello:
|
| YesPlan explicitly requires Seaside 3.0.7.1
| Yesplan explicitly requires Seaside-Testing 0.7
| Seaside-Testing explicitly requires Seaside 3.0.0-rc.2
|
| All project dependencies use the (default) version operator (#>=)
|
| Launching the load eventually triggers fetch operations for packages
| of Seaside 3.0.0-rc.2.
| However, I do not want this version of Seaside to load. I want the
| version specified in my Yesplan config.
|
| I have similar problems in the inverse direction: i.e. when I update
| the Seaside-Testing configuration to require the #stable Seaside
| version, it tries to fetch packages for a more recent Seaside
| version than I want to (i.e. for an older version of Yesplan):
|
| YesPlan explicitly requires Seaside 3.0.6.4
| Yesplan explicitly requires Seaside-Testing 0.7
| Seaside-Testing explicitly requires Seaside #stable
|
| It seems I want to be able to tell metacello to explicitly load a
| certain version of a project _regardless_ of what a dependent
| project's configuration has to say about that.
|
| The issue is that I want to protect my load from using any packages
| that I did not replicate to my local repository (I'm using a
| #repositoryOverrides: during the load). Now, with the first
| situation above, I would have expected that the dependency of
| SeasideTesting on an older version of Seaside would have been
| ignored. However, it's trying to fetch old packages which I do not
| have on my local repository. For the second situation, I did expect
| the problem but nevertheless I would like to avoid it.
|
| In general, this is a problem I experience frequently: some project's
| #stable version moved up a version but I do not want to follow that
| upgrade. Is it possible to do that without manually fixing the
| configuration file in each of the configurations I include?
|
| I hope you can make sense of my question ;-)
|
| Johan

Johan,

I've finally got the Metacello preview loading into pharo-1.4 and behaving reasonably:) ...So you should be using ConfigurationOfMetacelloPreview-dkh.19 or later.

Once you have ConfigurationOfMetacelloPreview-dkh.19 loaded the following expressions can be used to update to a later version (i.e., pick up bugfixes)

    Metacello image
        configuration: #('MetacelloPreview');
        get.
    Metacello image
        configuration: #('MetacelloPreview' );
        load.

or:

    Metacello image
        configuration: #('MetacelloPreview' );
        load: 'Tests'.

to load up the tests as examples. Now that I've got Pharo-1.4 working, I'll take a crack at making sure that the load runs cleanly for GemStone ...

Dale
----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Thursday, July 26, 2012 11:52:43 AM
| Subject: Re: metacello diamond project dependency problem
|
| Forgot: using pharo14 and gs24.  So that should work
|
|
| Johan (sent from my mobile)
|
| On 26 Jul 2012, at 19:16, Dale Henrichs <[hidden email]> wrote:
|
| > Johan,
| >
| > Sorry about the metacello group membership thing ... I had gotten a
| > gmail account a while back and then I (unfortunately) joined g+
| > and then google insisted that the gmail account be used for
| > logging in and then magically all of the notification mail that I
| > had carefully configured to come to my vmware mailbox has been
| > sent to my gmail account (which I never use) ... I'm not sure when
| > this happened and I only noticed recently that I wasn't receiving
| > mail that I expected to be getting (like metacello membership
| > pending) ... I've cc'd the metacello list so we can continue the
| > conversation there..
| >
| > Two things:
| >
| >  1. the fetching old versions of packages does happen ... they are
| >  not _loaded_ but they
| >     do get fetched ... this would be a tough nut to crack with the
| >     current version
| >     of Metacello
| >  2. I'm about to release (today or tomorrow) a pre-release version
| >  of Metacello that
| >     introduces a scripting API that is intended to allow you to
| >     "pin" projects to a
| >     particular version (without editting configs) and no fetching
| >     of packages from
| >     older versions will occur .... so you'd be the "perfect test
| >     case".
| >
| > This pre-release version of Metacello should not have any behavior
| > differences from the current released version of Metacello with
| > the exception of the addition of git/github support (which you
| > don't need) and the scripting api (which you do).
| >
| > So if you are willing I'd like you to attempt to use the
| > pre-release version of Metacello to get your job done ... I'm more
| > than willing to commit to fixing bugs and tweak features so that
| > you can get Metacello to work for you ...
| >
| > I am suggesting that you use the pre-release because the intent of
| > the features that I've added to the scripting api is to:
| >
| >  be able to tell metacello to explicitly load a
| >  certain version of a project _regardless_ of what a dependent
| >  project's configuration has to say about that.
| >
| > There are actually two features of the API that come into play:
| >
| >  1. the project registry
| >  2. the ability to customize upgrades/downgrades
| >
| > The project registry records the projectSpecs that you used when
| > loading the image ... so the api knows exactly what you loaded.
| > You can add a specification to the registry BEFORE the project is
| > actually loaded so that when a project has that project as a
| > dependency the version in the registry will be used. You can lock
| > project registrations so that an error will be thrown if an
| > attempt is made to load a different version of the specified
| > project.
| >
| > The customization comes into play when you hit a load expression
| > that causes a lock error or that you know will do something you
| > don't want...for every project upgrade/downgrade during a load,
| > you have the opportunity `allow` or `disallow` the action. By
| > default upgrades are allowed and downgrades are disallowed, but
| > you can specify your own rules ...
| >
| > In your case you will want to `lock` Seaside to a particular
| > version and repository:
| >
| >  Metacello new
| >    configuration: 'Seaside30';
| >    version: '3.0.7.1';
| >    repository: '<repository description for your override
| >    repository>';
| >    lock.
| >
| > Then when you load Seaside-Testing you use the api to deny
| > upgrades/downgrades for Seaside30 and bypass lock violation
| > errors:
| >
| >  Metacello new
| >    configuration: 'Seaside-Testing';
| >    version: #stable;
| >    repository: '<repositiory description for Seaside-Testing
| >    config>';
| >    onUpgrade: [:ex :existing :new |
| >      new baseName = 'Seaside30
| >        ifTrue: [ ex disallow ].
| >      ex pass];
| >    onDowngrade: [:ex :existing :new |
| >      new baseName = 'Seaside30
| >        ifTrue: [ ex disallow ].
| >      ex pass]
| >    load.
| >
| > Technically you can probably get by without the onUpgrade:
| > onDowngrade: blocks in this case, because the pre-registration of
| > Seaside30 should cause Seaside-Testing to use 3.0.7.1 instead of
| > 3.0.0-rc.2...
| >
| > So if you are willing to be a guinea pig, give me the particulars
| > of the version of pharo that you are using (pharo-1.3 and
| > pharo-1.4 are known to work ... pharo-2.0 has issues and I just
| > haven't tried pharo-1.2 and earlier versions yet ... it also known
| > to work on Squeak4.3, GemStone2.4 and GemStone3.1) and if you're
| > using something other that 1.3 or 1.4 I'll ensure that the api
| > works there.
| >
| > So what do you think?
| >
| > Dale
| >
| > [1] http://code.google.com/p/metacello/issues/detail?id=150
| > ----- Original Message -----
| > | From: "Johan Brichau" <[hidden email]>
| > | To: "Dale Henrichs" <[hidden email]>
| > | Sent: Thursday, July 26, 2012 8:18:22 AM
| > | Subject: metacello diamond project dependency problem
| > |
| > | Hi Dale,
| > |
| > | I wanted to send this to the metacello group, but I do not have
| > | access (yet).
| > | Since I'm stuck with it, I thought to ask you directly already.
| > |
| > | I have a problem with diamond project dependencies in metacello:
| > |
| > | YesPlan explicitly requires Seaside 3.0.7.1
| > | Yesplan explicitly requires Seaside-Testing 0.7
| > | Seaside-Testing explicitly requires Seaside 3.0.0-rc.2
| > |
| > | All project dependencies use the (default) version operator (#>=)
| > |
| > | Launching the load eventually triggers fetch operations for
| > | packages
| > | of Seaside 3.0.0-rc.2.
| > | However, I do not want this version of Seaside to load. I want
| > | the
| > | version specified in my Yesplan config.
| > |
| > | I have similar problems in the inverse direction: i.e. when I
| > | update
| > | the Seaside-Testing configuration to require the #stable Seaside
| > | version, it tries to fetch packages for a more recent Seaside
| > | version than I want to (i.e. for an older version of Yesplan):
| > |
| > | YesPlan explicitly requires Seaside 3.0.6.4
| > | Yesplan explicitly requires Seaside-Testing 0.7
| > | Seaside-Testing explicitly requires Seaside #stable
| > |
| > | It seems I want to be able to tell metacello to explicitly load a
| > | certain version of a project _regardless_ of what a dependent
| > | project's configuration has to say about that.
| > |
| > | The issue is that I want to protect my load from using any
| > | packages
| > | that I did not replicate to my local repository (I'm using a
| > | #repositoryOverrides: during the load). Now, with the first
| > | situation above, I would have expected that the dependency of
| > | SeasideTesting on an older version of Seaside would have been
| > | ignored. However, it's trying to fetch old packages which I do
| > | not
| > | have on my local repository. For the second situation, I did
| > | expect
| > | the problem but nevertheless I would like to avoid it.
| > |
| > | In general, this is a problem I experience frequently: some
| > | project's
| > | #stable version moved up a version but I do not want to follow
| > | that
| > | upgrade. Is it possible to do that without manually fixing the
| > | configuration file in each of the configurations I include?
| > |
| > | I hope you can make sense of my question ;-)
| > |
| > | Johan
|

Hi Dale,

Thanks.

I'm playing with it right now.

Maybe some quick questions already:

- is there a way to communicatie login & pass with a repository ?
 
- running the snippet below gives me the error that Metacello-Base cannot be resolved (although it's even loaded already):

 Metacello image
   baseline: 'Metacello';
   load: 'Tests'.

Maybe I should check out the changes you made right now? ;-)

Johan

On 27 Jul 2012, at 12:37, Dale Henrichs wrote:

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Friday, July 27, 2012 3:47:08 AM
| Subject: Re: metacello diamond project dependency problem
|
| Hi Dale,
|
| Thanks.
|
| I'm playing with it right now.
|
| Maybe some quick questions already:
|
| - is there a way to communicatie login & pass with a repository ?

ah ... haven't thought about that ... you can specify the login and password in a config but I haven't added that to the api yet ...

|  
| - running the snippet below gives me the error that Metacello-Base
| cannot be resolved (although it's even loaded already):
|
|  Metacello image
|    baseline: 'Metacello';
|    load: 'Tests'.

Yeah that was the part that I was working on with the more recent changes ...

|
| Maybe I should check out the changes you made right now? ;-)

Because of the bug itself, it might be easier to load the few packages manually directly from the repository (4d122a3372c4b27c76681ae72483fdac1cd4f8e8) ... then you'll get going ...

|
| Johan
|
| On 27 Jul 2012, at 12:37, Dale Henrichs wrote:
|
| > Johan,
| >
| > I've finally got the Metacello preview loading into pharo-1.4 and
| > behaving reasonably:) ...So you should be using
| > ConfigurationOfMetacelloPreview-dkh.19 or later.
| >
| > Once you have ConfigurationOfMetacelloPreview-dkh.19 loaded the
| > following expressions can be used to update to a later version
| > (i.e., pick up bugfixes)
| >
| >    Metacello image
| > configuration: #('MetacelloPreview');
| > get.
| >    Metacello image
| > configuration: #('MetacelloPreview' );
| > load.
| >
| > or:
| >
| >    Metacello image
| > configuration: #('MetacelloPreview' );
| > load: 'Tests'.
| >
| > to load up the tests as examples. Now that I've got Pharo-1.4
| > working, I'll take a crack at making sure that the load runs
| > cleanly for GemStone ...
| >
| > Dale
| > ----- Original Message -----
| > | From: "Johan Brichau" <[hidden email]>
| > | To: "Dale Henrichs" <[hidden email]>
| > | Cc: [hidden email]
| > | Sent: Thursday, July 26, 2012 11:52:43 AM
| > | Subject: Re: metacello diamond project dependency problem
| > |
| > | Forgot: using pharo14 and gs24.  So that should work
| > |
| > |
| > | Johan (sent from my mobile)
| > |
| > | On 26 Jul 2012, at 19:16, Dale Henrichs <[hidden email]>
| > | wrote:
| > |
| > | > Johan,
| > | >
| > | > Sorry about the metacello group membership thing ... I had
| > | > gotten a
| > | > gmail account a while back and then I (unfortunately) joined g+
| > | > and then google insisted that the gmail account be used for
| > | > logging in and then magically all of the notification mail that
| > | > I
| > | > had carefully configured to come to my vmware mailbox has been
| > | > sent to my gmail account (which I never use) ... I'm not sure
| > | > when
| > | > this happened and I only noticed recently that I wasn't
| > | > receiving
| > | > mail that I expected to be getting (like metacello membership
| > | > pending) ... I've cc'd the metacello list so we can continue
| > | > the
| > | > conversation there..
| > | >
| > | > Two things:
| > | >
| > | >  1. the fetching old versions of packages does happen ... they
| > | >  are
| > | >  not _loaded_ but they
| > | >     do get fetched ... this would be a tough nut to crack with
| > | >     the
| > | >     current version
| > | >     of Metacello
| > | >  2. I'm about to release (today or tomorrow) a pre-release
| > | >  version
| > | >  of Metacello that
| > | >     introduces a scripting API that is intended to allow you to
| > | >     "pin" projects to a
| > | >     particular version (without editting configs) and no
| > | >     fetching
| > | >     of packages from
| > | >     older versions will occur .... so you'd be the "perfect
| > | >     test
| > | >     case".
| > | >
| > | > This pre-release version of Metacello should not have any
| > | > behavior
| > | > differences from the current released version of Metacello with
| > | > the exception of the addition of git/github support (which you
| > | > don't need) and the scripting api (which you do).
| > | >
| > | > So if you are willing I'd like you to attempt to use the
| > | > pre-release version of Metacello to get your job done ... I'm
| > | > more
| > | > than willing to commit to fixing bugs and tweak features so
| > | > that
| > | > you can get Metacello to work for you ...
| > | >
| > | > I am suggesting that you use the pre-release because the intent
| > | > of
| > | > the features that I've added to the scripting api is to:
| > | >
| > | >  be able to tell metacello to explicitly load a
| > | >  certain version of a project _regardless_ of what a dependent
| > | >  project's configuration has to say about that.
| > | >
| > | > There are actually two features of the API that come into play:
| > | >
| > | >  1. the project registry
| > | >  2. the ability to customize upgrades/downgrades
| > | >
| > | > The project registry records the projectSpecs that you used
| > | > when
| > | > loading the image ... so the api knows exactly what you loaded.
| > | > You can add a specification to the registry BEFORE the project
| > | > is
| > | > actually loaded so that when a project has that project as a
| > | > dependency the version in the registry will be used. You can
| > | > lock
| > | > project registrations so that an error will be thrown if an
| > | > attempt is made to load a different version of the specified
| > | > project.
| > | >
| > | > The customization comes into play when you hit a load
| > | > expression
| > | > that causes a lock error or that you know will do something you
| > | > don't want...for every project upgrade/downgrade during a load,
| > | > you have the opportunity `allow` or `disallow` the action. By
| > | > default upgrades are allowed and downgrades are disallowed, but
| > | > you can specify your own rules ...
| > | >
| > | > In your case you will want to `lock` Seaside to a particular
| > | > version and repository:
| > | >
| > | >  Metacello new
| > | >    configuration: 'Seaside30';
| > | >    version: '3.0.7.1';
| > | >    repository: '<repository description for your override
| > | >    repository>';
| > | >    lock.
| > | >
| > | > Then when you load Seaside-Testing you use the api to deny
| > | > upgrades/downgrades for Seaside30 and bypass lock violation
| > | > errors:
| > | >
| > | >  Metacello new
| > | >    configuration: 'Seaside-Testing';
| > | >    version: #stable;
| > | >    repository: '<repositiory description for Seaside-Testing
| > | >    config>';
| > | >    onUpgrade: [:ex :existing :new |
| > | >      new baseName = 'Seaside30
| > | >        ifTrue: [ ex disallow ].
| > | >      ex pass];
| > | >    onDowngrade: [:ex :existing :new |
| > | >      new baseName = 'Seaside30
| > | >        ifTrue: [ ex disallow ].
| > | >      ex pass]
| > | >    load.
| > | >
| > | > Technically you can probably get by without the onUpgrade:
| > | > onDowngrade: blocks in this case, because the pre-registration
| > | > of
| > | > Seaside30 should cause Seaside-Testing to use 3.0.7.1 instead
| > | > of
| > | > 3.0.0-rc.2...
| > | >
| > | > So if you are willing to be a guinea pig, give me the
| > | > particulars
| > | > of the version of pharo that you are using (pharo-1.3 and
| > | > pharo-1.4 are known to work ... pharo-2.0 has issues and I just
| > | > haven't tried pharo-1.2 and earlier versions yet ... it also
| > | > known
| > | > to work on Squeak4.3, GemStone2.4 and GemStone3.1) and if
| > | > you're
| > | > using something other that 1.3 or 1.4 I'll ensure that the api
| > | > works there.
| > | >
| > | > So what do you think?
| > | >
| > | > Dale
| > | >
| > | > [1] http://code.google.com/p/metacello/issues/detail?id=150
| > | > ----- Original Message -----
| > | > | From: "Johan Brichau" <[hidden email]>
| > | > | To: "Dale Henrichs" <[hidden email]>
| > | > | Sent: Thursday, July 26, 2012 8:18:22 AM
| > | > | Subject: metacello diamond project dependency problem
| > | > |
| > | > | Hi Dale,
| > | > |
| > | > | I wanted to send this to the metacello group, but I do not
| > | > | have
| > | > | access (yet).
| > | > | Since I'm stuck with it, I thought to ask you directly
| > | > | already.
| > | > |
| > | > | I have a problem with diamond project dependencies in
| > | > | metacello:
| > | > |
| > | > | YesPlan explicitly requires Seaside 3.0.7.1
| > | > | Yesplan explicitly requires Seaside-Testing 0.7
| > | > | Seaside-Testing explicitly requires Seaside 3.0.0-rc.2
| > | > |
| > | > | All project dependencies use the (default) version operator
| > | > | (#>=)
| > | > |
| > | > | Launching the load eventually triggers fetch operations for
| > | > | packages
| > | > | of Seaside 3.0.0-rc.2.
| > | > | However, I do not want this version of Seaside to load. I
| > | > | want
| > | > | the
| > | > | version specified in my Yesplan config.
| > | > |
| > | > | I have similar problems in the inverse direction: i.e. when I
| > | > | update
| > | > | the Seaside-Testing configuration to require the #stable
| > | > | Seaside
| > | > | version, it tries to fetch packages for a more recent Seaside
| > | > | version than I want to (i.e. for an older version of
| > | > | Yesplan):
| > | > |
| > | > | YesPlan explicitly requires Seaside 3.0.6.4
| > | > | Yesplan explicitly requires Seaside-Testing 0.7
| > | > | Seaside-Testing explicitly requires Seaside #stable
| > | > |
| > | > | It seems I want to be able to tell metacello to explicitly
| > | > | load a
| > | > | certain version of a project _regardless_ of what a dependent
| > | > | project's configuration has to say about that.
| > | > |
| > | > | The issue is that I want to protect my load from using any
| > | > | packages
| > | > | that I did not replicate to my local repository (I'm using a
| > | > | #repositoryOverrides: during the load). Now, with the first
| > | > | situation above, I would have expected that the dependency of
| > | > | SeasideTesting on an older version of Seaside would have been
| > | > | ignored. However, it's trying to fetch old packages which I
| > | > | do
| > | > | not
| > | > | have on my local repository. For the second situation, I did
| > | > | expect
| > | > | the problem but nevertheless I would like to avoid it.
| > | > |
| > | > | In general, this is a problem I experience frequently: some
| > | > | project's
| > | > | #stable version moved up a version but I do not want to
| > | > | follow
| > | > | that
| > | > | upgrade. Is it possible to do that without manually fixing
| > | > | the
| > | > | configuration file in each of the configurations I include?
| > | > |
| > | > | I hope you can make sense of my question ;-)
| > | > |
| > | > | Johan
| > |
|
|

GemStone should load up and work as well ... start with GLASS 1.0-beta.8.7.2 and run the install script ...

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Friday, July 27, 2012 3:47:08 AM
| Subject: Re: metacello diamond project dependency problem
|
| Hi Dale,
|
| Thanks.
|
| I'm playing with it right now.
|
| Maybe some quick questions already:
|
| - is there a way to communicatie login & pass with a repository ?
|  
| - running the snippet below gives me the error that Metacello-Base
| cannot be resolved (although it's even loaded already):
|
|  Metacello image
|    baseline: 'Metacello';
|    load: 'Tests'.
|
| Maybe I should check out the changes you made right now? ;-)
|
| Johan
|
| On 27 Jul 2012, at 12:37, Dale Henrichs wrote:
|
| > Johan,
| >
| > I've finally got the Metacello preview loading into pharo-1.4 and
| > behaving reasonably:) ...So you should be using
| > ConfigurationOfMetacelloPreview-dkh.19 or later.
| >
| > Once you have ConfigurationOfMetacelloPreview-dkh.19 loaded the
| > following expressions can be used to update to a later version
| > (i.e., pick up bugfixes)
| >
| >    Metacello image
| > configuration: #('MetacelloPreview');
| > get.
| >    Metacello image
| > configuration: #('MetacelloPreview' );
| > load.
| >
| > or:
| >
| >    Metacello image
| > configuration: #('MetacelloPreview' );
| > load: 'Tests'.
| >
| > to load up the tests as examples. Now that I've got Pharo-1.4
| > working, I'll take a crack at making sure that the load runs
| > cleanly for GemStone ...
| >
| > Dale
| > ----- Original Message -----
| > | From: "Johan Brichau" <[hidden email]>
| > | To: "Dale Henrichs" <[hidden email]>
| > | Cc: [hidden email]
| > | Sent: Thursday, July 26, 2012 11:52:43 AM
| > | Subject: Re: metacello diamond project dependency problem
| > |
| > | Forgot: using pharo14 and gs24.  So that should work
| > |
| > |
| > | Johan (sent from my mobile)
| > |
| > | On 26 Jul 2012, at 19:16, Dale Henrichs <[hidden email]>
| > | wrote:
| > |
| > | > Johan,
| > | >
| > | > Sorry about the metacello group membership thing ... I had
| > | > gotten a
| > | > gmail account a while back and then I (unfortunately) joined g+
| > | > and then google insisted that the gmail account be used for
| > | > logging in and then magically all of the notification mail that
| > | > I
| > | > had carefully configured to come to my vmware mailbox has been
| > | > sent to my gmail account (which I never use) ... I'm not sure
| > | > when
| > | > this happened and I only noticed recently that I wasn't
| > | > receiving
| > | > mail that I expected to be getting (like metacello membership
| > | > pending) ... I've cc'd the metacello list so we can continue
| > | > the
| > | > conversation there..
| > | >
| > | > Two things:
| > | >
| > | >  1. the fetching old versions of packages does happen ... they
| > | >  are
| > | >  not _loaded_ but they
| > | >     do get fetched ... this would be a tough nut to crack with
| > | >     the
| > | >     current version
| > | >     of Metacello
| > | >  2. I'm about to release (today or tomorrow) a pre-release
| > | >  version
| > | >  of Metacello that
| > | >     introduces a scripting API that is intended to allow you to
| > | >     "pin" projects to a
| > | >     particular version (without editting configs) and no
| > | >     fetching
| > | >     of packages from
| > | >     older versions will occur .... so you'd be the "perfect
| > | >     test
| > | >     case".
| > | >
| > | > This pre-release version of Metacello should not have any
| > | > behavior
| > | > differences from the current released version of Metacello with
| > | > the exception of the addition of git/github support (which you
| > | > don't need) and the scripting api (which you do).
| > | >
| > | > So if you are willing I'd like you to attempt to use the
| > | > pre-release version of Metacello to get your job done ... I'm
| > | > more
| > | > than willing to commit to fixing bugs and tweak features so
| > | > that
| > | > you can get Metacello to work for you ...
| > | >
| > | > I am suggesting that you use the pre-release because the intent
| > | > of
| > | > the features that I've added to the scripting api is to:
| > | >
| > | >  be able to tell metacello to explicitly load a
| > | >  certain version of a project _regardless_ of what a dependent
| > | >  project's configuration has to say about that.
| > | >
| > | > There are actually two features of the API that come into play:
| > | >
| > | >  1. the project registry
| > | >  2. the ability to customize upgrades/downgrades
| > | >
| > | > The project registry records the projectSpecs that you used
| > | > when
| > | > loading the image ... so the api knows exactly what you loaded.
| > | > You can add a specification to the registry BEFORE the project
| > | > is
| > | > actually loaded so that when a project has that project as a
| > | > dependency the version in the registry will be used. You can
| > | > lock
| > | > project registrations so that an error will be thrown if an
| > | > attempt is made to load a different version of the specified
| > | > project.
| > | >
| > | > The customization comes into play when you hit a load
| > | > expression
| > | > that causes a lock error or that you know will do something you
| > | > don't want...for every project upgrade/downgrade during a load,
| > | > you have the opportunity `allow` or `disallow` the action. By
| > | > default upgrades are allowed and downgrades are disallowed, but
| > | > you can specify your own rules ...
| > | >
| > | > In your case you will want to `lock` Seaside to a particular
| > | > version and repository:
| > | >
| > | >  Metacello new
| > | >    configuration: 'Seaside30';
| > | >    version: '3.0.7.1';
| > | >    repository: '<repository description for your override
| > | >    repository>';
| > | >    lock.
| > | >
| > | > Then when you load Seaside-Testing you use the api to deny
| > | > upgrades/downgrades for Seaside30 and bypass lock violation
| > | > errors:
| > | >
| > | >  Metacello new
| > | >    configuration: 'Seaside-Testing';
| > | >    version: #stable;
| > | >    repository: '<repositiory description for Seaside-Testing
| > | >    config>';
| > | >    onUpgrade: [:ex :existing :new |
| > | >      new baseName = 'Seaside30
| > | >        ifTrue: [ ex disallow ].
| > | >      ex pass];
| > | >    onDowngrade: [:ex :existing :new |
| > | >      new baseName = 'Seaside30
| > | >        ifTrue: [ ex disallow ].
| > | >      ex pass]
| > | >    load.
| > | >
| > | > Technically you can probably get by without the onUpgrade:
| > | > onDowngrade: blocks in this case, because the pre-registration
| > | > of
| > | > Seaside30 should cause Seaside-Testing to use 3.0.7.1 instead
| > | > of
| > | > 3.0.0-rc.2...
| > | >
| > | > So if you are willing to be a guinea pig, give me the
| > | > particulars
| > | > of the version of pharo that you are using (pharo-1.3 and
| > | > pharo-1.4 are known to work ... pharo-2.0 has issues and I just
| > | > haven't tried pharo-1.2 and earlier versions yet ... it also
| > | > known
| > | > to work on Squeak4.3, GemStone2.4 and GemStone3.1) and if
| > | > you're
| > | > using something other that 1.3 or 1.4 I'll ensure that the api
| > | > works there.
| > | >
| > | > So what do you think?
| > | >
| > | > Dale
| > | >
| > | > [1] http://code.google.com/p/metacello/issues/detail?id=150
| > | > ----- Original Message -----
| > | > | From: "Johan Brichau" <[hidden email]>
| > | > | To: "Dale Henrichs" <[hidden email]>
| > | > | Sent: Thursday, July 26, 2012 8:18:22 AM
| > | > | Subject: metacello diamond project dependency problem
| > | > |
| > | > | Hi Dale,
| > | > |
| > | > | I wanted to send this to the metacello group, but I do not
| > | > | have
| > | > | access (yet).
| > | > | Since I'm stuck with it, I thought to ask you directly
| > | > | already.
| > | > |
| > | > | I have a problem with diamond project dependencies in
| > | > | metacello:
| > | > |
| > | > | YesPlan explicitly requires Seaside 3.0.7.1
| > | > | Yesplan explicitly requires Seaside-Testing 0.7
| > | > | Seaside-Testing explicitly requires Seaside 3.0.0-rc.2
| > | > |
| > | > | All project dependencies use the (default) version operator
| > | > | (#>=)
| > | > |
| > | > | Launching the load eventually triggers fetch operations for
| > | > | packages
| > | > | of Seaside 3.0.0-rc.2.
| > | > | However, I do not want this version of Seaside to load. I
| > | > | want
| > | > | the
| > | > | version specified in my Yesplan config.
| > | > |
| > | > | I have similar problems in the inverse direction: i.e. when I
| > | > | update
| > | > | the Seaside-Testing configuration to require the #stable
| > | > | Seaside
| > | > | version, it tries to fetch packages for a more recent Seaside
| > | > | version than I want to (i.e. for an older version of
| > | > | Yesplan):
| > | > |
| > | > | YesPlan explicitly requires Seaside 3.0.6.4
| > | > | Yesplan explicitly requires Seaside-Testing 0.7
| > | > | Seaside-Testing explicitly requires Seaside #stable
| > | > |
| > | > | It seems I want to be able to tell metacello to explicitly
| > | > | load a
| > | > | certain version of a project _regardless_ of what a dependent
| > | > | project's configuration has to say about that.
| > | > |
| > | > | The issue is that I want to protect my load from using any
| > | > | packages
| > | > | that I did not replicate to my local repository (I'm using a
| > | > | #repositoryOverrides: during the load). Now, with the first
| > | > | situation above, I would have expected that the dependency of
| > | > | SeasideTesting on an older version of Seaside would have been
| > | > | ignored. However, it's trying to fetch old packages which I
| > | > | do
| > | > | not
| > | > | have on my local repository. For the second situation, I did
| > | > | expect
| > | > | the problem but nevertheless I would like to avoid it.
| > | > |
| > | > | In general, this is a problem I experience frequently: some
| > | > | project's
| > | > | #stable version moved up a version but I do not want to
| > | > | follow
| > | > | that
| > | > | upgrade. Is it possible to do that without manually fixing
| > | > | the
| > | > | configuration file in each of the configurations I include?
| > | > |
| > | > | I hope you can make sense of my question ;-)
| > | > |
| > | > | Johan
| > |
|
|

The travis ci builds showed another problem and I'm now addressing the failing tests ... when travis runs clean I'll publish a new version ... and let you know

Dale

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "Johan Brichau" <[hidden email]>
| Cc: [hidden email]
| Sent: Friday, July 27, 2012 5:01:37 AM
| Subject: Re: metacello diamond project dependency problem
|
| GemStone should load up and work as well ... start with GLASS
| 1.0-beta.8.7.2 and run the install script ...
|
| ----- Original Message -----
| | From: "Johan Brichau" <[hidden email]>
| | To: "Dale Henrichs" <[hidden email]>
| | Cc: [hidden email]
| | Sent: Friday, July 27, 2012 3:47:08 AM
| | Subject: Re: metacello diamond project dependency problem
| |
| | Hi Dale,
| |
| | Thanks.
| |
| | I'm playing with it right now.
| |
| | Maybe some quick questions already:
| |
| | - is there a way to communicatie login & pass with a repository ?
| |  
| | - running the snippet below gives me the error that Metacello-Base
| | cannot be resolved (although it's even loaded already):
| |
| |  Metacello image
| |    baseline: 'Metacello';
| |    load: 'Tests'.
| |
| | Maybe I should check out the changes you made right now? ;-)
| |
| | Johan
| |
| | On 27 Jul 2012, at 12:37, Dale Henrichs wrote:
| |
| | > Johan,
| | >
| | > I've finally got the Metacello preview loading into pharo-1.4 and
| | > behaving reasonably:) ...So you should be using
| | > ConfigurationOfMetacelloPreview-dkh.19 or later.
| | >
| | > Once you have ConfigurationOfMetacelloPreview-dkh.19 loaded the
| | > following expressions can be used to update to a later version
| | > (i.e., pick up bugfixes)
| | >
| | >    Metacello image
| | > configuration: #('MetacelloPreview');
| | > get.
| | >    Metacello image
| | > configuration: #('MetacelloPreview' );
| | > load.
| | >
| | > or:
| | >
| | >    Metacello image
| | > configuration: #('MetacelloPreview' );
| | > load: 'Tests'.
| | >
| | > to load up the tests as examples. Now that I've got Pharo-1.4
| | > working, I'll take a crack at making sure that the load runs
| | > cleanly for GemStone ...
| | >
| | > Dale
| | > ----- Original Message -----
| | > | From: "Johan Brichau" <[hidden email]>
| | > | To: "Dale Henrichs" <[hidden email]>
| | > | Cc: [hidden email]
| | > | Sent: Thursday, July 26, 2012 11:52:43 AM
| | > | Subject: Re: metacello diamond project dependency problem
| | > |
| | > | Forgot: using pharo14 and gs24.  So that should work
| | > |
| | > |
| | > | Johan (sent from my mobile)
| | > |
| | > | On 26 Jul 2012, at 19:16, Dale Henrichs <[hidden email]>
| | > | wrote:
| | > |
| | > | > Johan,
| | > | >
| | > | > Sorry about the metacello group membership thing ... I had
| | > | > gotten a
| | > | > gmail account a while back and then I (unfortunately) joined
| | > | > g+
| | > | > and then google insisted that the gmail account be used for
| | > | > logging in and then magically all of the notification mail
| | > | > that
| | > | > I
| | > | > had carefully configured to come to my vmware mailbox has
| | > | > been
| | > | > sent to my gmail account (which I never use) ... I'm not sure
| | > | > when
| | > | > this happened and I only noticed recently that I wasn't
| | > | > receiving
| | > | > mail that I expected to be getting (like metacello membership
| | > | > pending) ... I've cc'd the metacello list so we can continue
| | > | > the
| | > | > conversation there..
| | > | >
| | > | > Two things:
| | > | >
| | > | >  1. the fetching old versions of packages does happen ...
| | > | >  they
| | > | >  are
| | > | >  not _loaded_ but they
| | > | >     do get fetched ... this would be a tough nut to crack
| | > | >     with
| | > | >     the
| | > | >     current version
| | > | >     of Metacello
| | > | >  2. I'm about to release (today or tomorrow) a pre-release
| | > | >  version
| | > | >  of Metacello that
| | > | >     introduces a scripting API that is intended to allow you
| | > | >     to
| | > | >     "pin" projects to a
| | > | >     particular version (without editting configs) and no
| | > | >     fetching
| | > | >     of packages from
| | > | >     older versions will occur .... so you'd be the "perfect
| | > | >     test
| | > | >     case".
| | > | >
| | > | > This pre-release version of Metacello should not have any
| | > | > behavior
| | > | > differences from the current released version of Metacello
| | > | > with
| | > | > the exception of the addition of git/github support (which
| | > | > you
| | > | > don't need) and the scripting api (which you do).
| | > | >
| | > | > So if you are willing I'd like you to attempt to use the
| | > | > pre-release version of Metacello to get your job done ... I'm
| | > | > more
| | > | > than willing to commit to fixing bugs and tweak features so
| | > | > that
| | > | > you can get Metacello to work for you ...
| | > | >
| | > | > I am suggesting that you use the pre-release because the
| | > | > intent
| | > | > of
| | > | > the features that I've added to the scripting api is to:
| | > | >
| | > | >  be able to tell metacello to explicitly load a
| | > | >  certain version of a project _regardless_ of what a
| | > | >  dependent
| | > | >  project's configuration has to say about that.
| | > | >
| | > | > There are actually two features of the API that come into
| | > | > play:
| | > | >
| | > | >  1. the project registry
| | > | >  2. the ability to customize upgrades/downgrades
| | > | >
| | > | > The project registry records the projectSpecs that you used
| | > | > when
| | > | > loading the image ... so the api knows exactly what you
| | > | > loaded.
| | > | > You can add a specification to the registry BEFORE the
| | > | > project
| | > | > is
| | > | > actually loaded so that when a project has that project as a
| | > | > dependency the version in the registry will be used. You can
| | > | > lock
| | > | > project registrations so that an error will be thrown if an
| | > | > attempt is made to load a different version of the specified
| | > | > project.
| | > | >
| | > | > The customization comes into play when you hit a load
| | > | > expression
| | > | > that causes a lock error or that you know will do something
| | > | > you
| | > | > don't want...for every project upgrade/downgrade during a
| | > | > load,
| | > | > you have the opportunity `allow` or `disallow` the action. By
| | > | > default upgrades are allowed and downgrades are disallowed,
| | > | > but
| | > | > you can specify your own rules ...
| | > | >
| | > | > In your case you will want to `lock` Seaside to a particular
| | > | > version and repository:
| | > | >
| | > | >  Metacello new
| | > | >    configuration: 'Seaside30';
| | > | >    version: '3.0.7.1';
| | > | >    repository: '<repository description for your override
| | > | >    repository>';
| | > | >    lock.
| | > | >
| | > | > Then when you load Seaside-Testing you use the api to deny
| | > | > upgrades/downgrades for Seaside30 and bypass lock violation
| | > | > errors:
| | > | >
| | > | >  Metacello new
| | > | >    configuration: 'Seaside-Testing';
| | > | >    version: #stable;
| | > | >    repository: '<repositiory description for Seaside-Testing
| | > | >    config>';
| | > | >    onUpgrade: [:ex :existing :new |
| | > | >      new baseName = 'Seaside30
| | > | >        ifTrue: [ ex disallow ].
| | > | >      ex pass];
| | > | >    onDowngrade: [:ex :existing :new |
| | > | >      new baseName = 'Seaside30
| | > | >        ifTrue: [ ex disallow ].
| | > | >      ex pass]
| | > | >    load.
| | > | >
| | > | > Technically you can probably get by without the onUpgrade:
| | > | > onDowngrade: blocks in this case, because the
| | > | > pre-registration
| | > | > of
| | > | > Seaside30 should cause Seaside-Testing to use 3.0.7.1 instead
| | > | > of
| | > | > 3.0.0-rc.2...
| | > | >
| | > | > So if you are willing to be a guinea pig, give me the
| | > | > particulars
| | > | > of the version of pharo that you are using (pharo-1.3 and
| | > | > pharo-1.4 are known to work ... pharo-2.0 has issues and I
| | > | > just
| | > | > haven't tried pharo-1.2 and earlier versions yet ... it also
| | > | > known
| | > | > to work on Squeak4.3, GemStone2.4 and GemStone3.1) and if
| | > | > you're
| | > | > using something other that 1.3 or 1.4 I'll ensure that the
| | > | > api
| | > | > works there.
| | > | >
| | > | > So what do you think?
| | > | >
| | > | > Dale
| | > | >
| | > | > [1] http://code.google.com/p/metacello/issues/detail?id=150
| | > | > ----- Original Message -----
| | > | > | From: "Johan Brichau" <[hidden email]>
| | > | > | To: "Dale Henrichs" <[hidden email]>
| | > | > | Sent: Thursday, July 26, 2012 8:18:22 AM
| | > | > | Subject: metacello diamond project dependency problem
| | > | > |
| | > | > | Hi Dale,
| | > | > |
| | > | > | I wanted to send this to the metacello group, but I do not
| | > | > | have
| | > | > | access (yet).
| | > | > | Since I'm stuck with it, I thought to ask you directly
| | > | > | already.
| | > | > |
| | > | > | I have a problem with diamond project dependencies in
| | > | > | metacello:
| | > | > |
| | > | > | YesPlan explicitly requires Seaside 3.0.7.1
| | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| | > | > | Seaside-Testing explicitly requires Seaside 3.0.0-rc.2
| | > | > |
| | > | > | All project dependencies use the (default) version operator
| | > | > | (#>=)
| | > | > |
| | > | > | Launching the load eventually triggers fetch operations for
| | > | > | packages
| | > | > | of Seaside 3.0.0-rc.2.
| | > | > | However, I do not want this version of Seaside to load. I
| | > | > | want
| | > | > | the
| | > | > | version specified in my Yesplan config.
| | > | > |
| | > | > | I have similar problems in the inverse direction: i.e. when
| | > | > | I
| | > | > | update
| | > | > | the Seaside-Testing configuration to require the #stable
| | > | > | Seaside
| | > | > | version, it tries to fetch packages for a more recent
| | > | > | Seaside
| | > | > | version than I want to (i.e. for an older version of
| | > | > | Yesplan):
| | > | > |
| | > | > | YesPlan explicitly requires Seaside 3.0.6.4
| | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| | > | > | Seaside-Testing explicitly requires Seaside #stable
| | > | > |
| | > | > | It seems I want to be able to tell metacello to explicitly
| | > | > | load a
| | > | > | certain version of a project _regardless_ of what a
| | > | > | dependent
| | > | > | project's configuration has to say about that.
| | > | > |
| | > | > | The issue is that I want to protect my load from using any
| | > | > | packages
| | > | > | that I did not replicate to my local repository (I'm using
| | > | > | a
| | > | > | #repositoryOverrides: during the load). Now, with the first
| | > | > | situation above, I would have expected that the dependency
| | > | > | of
| | > | > | SeasideTesting on an older version of Seaside would have
| | > | > | been
| | > | > | ignored. However, it's trying to fetch old packages which I
| | > | > | do
| | > | > | not
| | > | > | have on my local repository. For the second situation, I
| | > | > | did
| | > | > | expect
| | > | > | the problem but nevertheless I would like to avoid it.
| | > | > |
| | > | > | In general, this is a problem I experience frequently: some
| | > | > | project's
| | > | > | #stable version moved up a version but I do not want to
| | > | > | follow
| | > | > | that
| | > | > | upgrade. Is it possible to do that without manually fixing
| | > | > | the
| | > | > | configuration file in each of the configurations I include?
| | > | > |
| | > | > | I hope you can make sense of my question ;-)
| | > | > |
| | > | > | Johan
| | > |
| |
| |
|

Looks like all builds are running clean [1] ... just a few more minutes.

Dale

[1] http://travis-ci.org/#!/dalehenrich/metacello-work/builds/1968710
----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "Johan Brichau" <[hidden email]>
| Cc: [hidden email]
| Sent: Friday, July 27, 2012 5:04:42 AM
| Subject: [Metacello] Re: metacello diamond project dependency problem
|
| The travis ci builds showed another problem and I'm now addressing
| the failing tests ... when travis runs clean I'll publish a new
| version ... and let you know
|
| Dale
|
| ----- Original Message -----
| | From: "Dale Henrichs" <[hidden email]>
| | To: "Johan Brichau" <[hidden email]>
| | Cc: [hidden email]
| | Sent: Friday, July 27, 2012 5:01:37 AM
| | Subject: Re: metacello diamond project dependency problem
| |
| | GemStone should load up and work as well ... start with GLASS
| | 1.0-beta.8.7.2 and run the install script ...
| |
| | ----- Original Message -----
| | | From: "Johan Brichau" <[hidden email]>
| | | To: "Dale Henrichs" <[hidden email]>
| | | Cc: [hidden email]
| | | Sent: Friday, July 27, 2012 3:47:08 AM
| | | Subject: Re: metacello diamond project dependency problem
| | |
| | | Hi Dale,
| | |
| | | Thanks.
| | |
| | | I'm playing with it right now.
| | |
| | | Maybe some quick questions already:
| | |
| | | - is there a way to communicatie login & pass with a repository ?
| | |  
| | | - running the snippet below gives me the error that
| | | Metacello-Base
| | | cannot be resolved (although it's even loaded already):
| | |
| | |  Metacello image
| | |    baseline: 'Metacello';
| | |    load: 'Tests'.
| | |
| | | Maybe I should check out the changes you made right now? ;-)
| | |
| | | Johan
| | |
| | | On 27 Jul 2012, at 12:37, Dale Henrichs wrote:
| | |
| | | > Johan,
| | | >
| | | > I've finally got the Metacello preview loading into pharo-1.4
| | | > and
| | | > behaving reasonably:) ...So you should be using
| | | > ConfigurationOfMetacelloPreview-dkh.19 or later.
| | | >
| | | > Once you have ConfigurationOfMetacelloPreview-dkh.19 loaded the
| | | > following expressions can be used to update to a later version
| | | > (i.e., pick up bugfixes)
| | | >
| | | >    Metacello image
| | | > configuration: #('MetacelloPreview');
| | | > get.
| | | >    Metacello image
| | | > configuration: #('MetacelloPreview' );
| | | > load.
| | | >
| | | > or:
| | | >
| | | >    Metacello image
| | | > configuration: #('MetacelloPreview' );
| | | > load: 'Tests'.
| | | >
| | | > to load up the tests as examples. Now that I've got Pharo-1.4
| | | > working, I'll take a crack at making sure that the load runs
| | | > cleanly for GemStone ...
| | | >
| | | > Dale
| | | > ----- Original Message -----
| | | > | From: "Johan Brichau" <[hidden email]>
| | | > | To: "Dale Henrichs" <[hidden email]>
| | | > | Cc: [hidden email]
| | | > | Sent: Thursday, July 26, 2012 11:52:43 AM
| | | > | Subject: Re: metacello diamond project dependency problem
| | | > |
| | | > | Forgot: using pharo14 and gs24.  So that should work
| | | > |
| | | > |
| | | > | Johan (sent from my mobile)
| | | > |
| | | > | On 26 Jul 2012, at 19:16, Dale Henrichs <[hidden email]>
| | | > | wrote:
| | | > |
| | | > | > Johan,
| | | > | >
| | | > | > Sorry about the metacello group membership thing ... I had
| | | > | > gotten a
| | | > | > gmail account a while back and then I (unfortunately)
| | | > | > joined
| | | > | > g+
| | | > | > and then google insisted that the gmail account be used for
| | | > | > logging in and then magically all of the notification mail
| | | > | > that
| | | > | > I
| | | > | > had carefully configured to come to my vmware mailbox has
| | | > | > been
| | | > | > sent to my gmail account (which I never use) ... I'm not
| | | > | > sure
| | | > | > when
| | | > | > this happened and I only noticed recently that I wasn't
| | | > | > receiving
| | | > | > mail that I expected to be getting (like metacello
| | | > | > membership
| | | > | > pending) ... I've cc'd the metacello list so we can
| | | > | > continue
| | | > | > the
| | | > | > conversation there..
| | | > | >
| | | > | > Two things:
| | | > | >
| | | > | >  1. the fetching old versions of packages does happen ...
| | | > | >  they
| | | > | >  are
| | | > | >  not _loaded_ but they
| | | > | >     do get fetched ... this would be a tough nut to crack
| | | > | >     with
| | | > | >     the
| | | > | >     current version
| | | > | >     of Metacello
| | | > | >  2. I'm about to release (today or tomorrow) a pre-release
| | | > | >  version
| | | > | >  of Metacello that
| | | > | >     introduces a scripting API that is intended to allow
| | | > | >     you
| | | > | >     to
| | | > | >     "pin" projects to a
| | | > | >     particular version (without editting configs) and no
| | | > | >     fetching
| | | > | >     of packages from
| | | > | >     older versions will occur .... so you'd be the "perfect
| | | > | >     test
| | | > | >     case".
| | | > | >
| | | > | > This pre-release version of Metacello should not have any
| | | > | > behavior
| | | > | > differences from the current released version of Metacello
| | | > | > with
| | | > | > the exception of the addition of git/github support (which
| | | > | > you
| | | > | > don't need) and the scripting api (which you do).
| | | > | >
| | | > | > So if you are willing I'd like you to attempt to use the
| | | > | > pre-release version of Metacello to get your job done ...
| | | > | > I'm
| | | > | > more
| | | > | > than willing to commit to fixing bugs and tweak features so
| | | > | > that
| | | > | > you can get Metacello to work for you ...
| | | > | >
| | | > | > I am suggesting that you use the pre-release because the
| | | > | > intent
| | | > | > of
| | | > | > the features that I've added to the scripting api is to:
| | | > | >
| | | > | >  be able to tell metacello to explicitly load a
| | | > | >  certain version of a project _regardless_ of what a
| | | > | >  dependent
| | | > | >  project's configuration has to say about that.
| | | > | >
| | | > | > There are actually two features of the API that come into
| | | > | > play:
| | | > | >
| | | > | >  1. the project registry
| | | > | >  2. the ability to customize upgrades/downgrades
| | | > | >
| | | > | > The project registry records the projectSpecs that you used
| | | > | > when
| | | > | > loading the image ... so the api knows exactly what you
| | | > | > loaded.
| | | > | > You can add a specification to the registry BEFORE the
| | | > | > project
| | | > | > is
| | | > | > actually loaded so that when a project has that project as
| | | > | > a
| | | > | > dependency the version in the registry will be used. You
| | | > | > can
| | | > | > lock
| | | > | > project registrations so that an error will be thrown if an
| | | > | > attempt is made to load a different version of the
| | | > | > specified
| | | > | > project.
| | | > | >
| | | > | > The customization comes into play when you hit a load
| | | > | > expression
| | | > | > that causes a lock error or that you know will do something
| | | > | > you
| | | > | > don't want...for every project upgrade/downgrade during a
| | | > | > load,
| | | > | > you have the opportunity `allow` or `disallow` the action.
| | | > | > By
| | | > | > default upgrades are allowed and downgrades are disallowed,
| | | > | > but
| | | > | > you can specify your own rules ...
| | | > | >
| | | > | > In your case you will want to `lock` Seaside to a
| | | > | > particular
| | | > | > version and repository:
| | | > | >
| | | > | >  Metacello new
| | | > | >    configuration: 'Seaside30';
| | | > | >    version: '3.0.7.1';
| | | > | >    repository: '<repository description for your override
| | | > | >    repository>';
| | | > | >    lock.
| | | > | >
| | | > | > Then when you load Seaside-Testing you use the api to deny
| | | > | > upgrades/downgrades for Seaside30 and bypass lock violation
| | | > | > errors:
| | | > | >
| | | > | >  Metacello new
| | | > | >    configuration: 'Seaside-Testing';
| | | > | >    version: #stable;
| | | > | >    repository: '<repositiory description for
| | | > | >    Seaside-Testing
| | | > | >    config>';
| | | > | >    onUpgrade: [:ex :existing :new |
| | | > | >      new baseName = 'Seaside30
| | | > | >        ifTrue: [ ex disallow ].
| | | > | >      ex pass];
| | | > | >    onDowngrade: [:ex :existing :new |
| | | > | >      new baseName = 'Seaside30
| | | > | >        ifTrue: [ ex disallow ].
| | | > | >      ex pass]
| | | > | >    load.
| | | > | >
| | | > | > Technically you can probably get by without the onUpgrade:
| | | > | > onDowngrade: blocks in this case, because the
| | | > | > pre-registration
| | | > | > of
| | | > | > Seaside30 should cause Seaside-Testing to use 3.0.7.1
| | | > | > instead
| | | > | > of
| | | > | > 3.0.0-rc.2...
| | | > | >
| | | > | > So if you are willing to be a guinea pig, give me the
| | | > | > particulars
| | | > | > of the version of pharo that you are using (pharo-1.3 and
| | | > | > pharo-1.4 are known to work ... pharo-2.0 has issues and I
| | | > | > just
| | | > | > haven't tried pharo-1.2 and earlier versions yet ... it
| | | > | > also
| | | > | > known
| | | > | > to work on Squeak4.3, GemStone2.4 and GemStone3.1) and if
| | | > | > you're
| | | > | > using something other that 1.3 or 1.4 I'll ensure that the
| | | > | > api
| | | > | > works there.
| | | > | >
| | | > | > So what do you think?
| | | > | >
| | | > | > Dale
| | | > | >
| | | > | > [1] http://code.google.com/p/metacello/issues/detail?id=150
| | | > | > ----- Original Message -----
| | | > | > | From: "Johan Brichau" <[hidden email]>
| | | > | > | To: "Dale Henrichs" <[hidden email]>
| | | > | > | Sent: Thursday, July 26, 2012 8:18:22 AM
| | | > | > | Subject: metacello diamond project dependency problem
| | | > | > |
| | | > | > | Hi Dale,
| | | > | > |
| | | > | > | I wanted to send this to the metacello group, but I do
| | | > | > | not
| | | > | > | have
| | | > | > | access (yet).
| | | > | > | Since I'm stuck with it, I thought to ask you directly
| | | > | > | already.
| | | > | > |
| | | > | > | I have a problem with diamond project dependencies in
| | | > | > | metacello:
| | | > | > |
| | | > | > | YesPlan explicitly requires Seaside 3.0.7.1
| | | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| | | > | > | Seaside-Testing explicitly requires Seaside 3.0.0-rc.2
| | | > | > |
| | | > | > | All project dependencies use the (default) version
| | | > | > | operator
| | | > | > | (#>=)
| | | > | > |
| | | > | > | Launching the load eventually triggers fetch operations
| | | > | > | for
| | | > | > | packages
| | | > | > | of Seaside 3.0.0-rc.2.
| | | > | > | However, I do not want this version of Seaside to load. I
| | | > | > | want
| | | > | > | the
| | | > | > | version specified in my Yesplan config.
| | | > | > |
| | | > | > | I have similar problems in the inverse direction: i.e.
| | | > | > | when
| | | > | > | I
| | | > | > | update
| | | > | > | the Seaside-Testing configuration to require the #stable
| | | > | > | Seaside
| | | > | > | version, it tries to fetch packages for a more recent
| | | > | > | Seaside
| | | > | > | version than I want to (i.e. for an older version of
| | | > | > | Yesplan):
| | | > | > |
| | | > | > | YesPlan explicitly requires Seaside 3.0.6.4
| | | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| | | > | > | Seaside-Testing explicitly requires Seaside #stable
| | | > | > |
| | | > | > | It seems I want to be able to tell metacello to
| | | > | > | explicitly
| | | > | > | load a
| | | > | > | certain version of a project _regardless_ of what a
| | | > | > | dependent
| | | > | > | project's configuration has to say about that.
| | | > | > |
| | | > | > | The issue is that I want to protect my load from using
| | | > | > | any
| | | > | > | packages
| | | > | > | that I did not replicate to my local repository (I'm
| | | > | > | using
| | | > | > | a
| | | > | > | #repositoryOverrides: during the load). Now, with the
| | | > | > | first
| | | > | > | situation above, I would have expected that the
| | | > | > | dependency
| | | > | > | of
| | | > | > | SeasideTesting on an older version of Seaside would have
| | | > | > | been
| | | > | > | ignored. However, it's trying to fetch old packages which
| | | > | > | I
| | | > | > | do
| | | > | > | not
| | | > | > | have on my local repository. For the second situation, I
| | | > | > | did
| | | > | > | expect
| | | > | > | the problem but nevertheless I would like to avoid it.
| | | > | > |
| | | > | > | In general, this is a problem I experience frequently:
| | | > | > | some
| | | > | > | project's
| | | > | > | #stable version moved up a version but I do not want to
| | | > | > | follow
| | | > | > | that
| | | > | > | upgrade. Is it possible to do that without manually
| | | > | > | fixing
| | | > | > | the
| | | > | > | configuration file in each of the configurations I
| | | > | > | include?
| | | > | > |
| | | > | > | I hope you can make sense of my question ;-)
| | | > | > |
| | | > | > | Johan
| | | > |
| | |
| | |
| |
|

Hi Dale,

Late night work? ;-)

I'm making progress as well. It seems I can use it to address my problem because I got Yesplan to load correctly from the local repositories.

I'll get back with my experiences

On 27 Jul 2012, at 14:04, Dale Henrichs wrote:

Haha, yeah sometimes you just have to just keep pushing hard... I didn't get a chance to actually start until after dinner a meeting took up most of the afternoon, and I got tired of delaying the release ...

ConfigurationOfMetacelloPreview-dkh.21 looks like it's in pretty good shape... tests are green so I'll be calling it a night, errr day.

I'll be interested in seeing your load script and hearing what you think ...

I feel real good about the underlying foundation and implementation and I like the basic API elements, but I do think that scripts can be made even more compact.

But right now is not the time to fine tune the api ... need to understand which of the features are helping and which ones are hindering...

Dale

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Friday, July 27, 2012 5:14:03 AM
| Subject: Re: metacello diamond project dependency problem
|
| Hi Dale,
|
| Late night work? ;-)
|
| I'm making progress as well. It seems I can use it to address my
| problem because I got Yesplan to load correctly from the local
| repositories.
|
| I'll get back with my experiences
|
| On 27 Jul 2012, at 14:04, Dale Henrichs wrote:
|
| > The travis ci builds showed another problem and I'm now addressing
| > the failing tests ... when travis runs clean I'll publish a new
| > version ... and let you know
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Dale Henrichs" <[hidden email]>
| > | To: "Johan Brichau" <[hidden email]>
| > | Cc: [hidden email]
| > | Sent: Friday, July 27, 2012 5:01:37 AM
| > | Subject: Re: metacello diamond project dependency problem
| > |
| > | GemStone should load up and work as well ... start with GLASS
| > | 1.0-beta.8.7.2 and run the install script ...
| > |
| > | ----- Original Message -----
| > | | From: "Johan Brichau" <[hidden email]>
| > | | To: "Dale Henrichs" <[hidden email]>
| > | | Cc: [hidden email]
| > | | Sent: Friday, July 27, 2012 3:47:08 AM
| > | | Subject: Re: metacello diamond project dependency problem
| > | |
| > | | Hi Dale,
| > | |
| > | | Thanks.
| > | |
| > | | I'm playing with it right now.
| > | |
| > | | Maybe some quick questions already:
| > | |
| > | | - is there a way to communicatie login & pass with a repository
| > | | ?
| > | |  
| > | | - running the snippet below gives me the error that
| > | | Metacello-Base
| > | | cannot be resolved (although it's even loaded already):
| > | |
| > | |  Metacello image
| > | |    baseline: 'Metacello';
| > | |    load: 'Tests'.
| > | |
| > | | Maybe I should check out the changes you made right now? ;-)
| > | |
| > | | Johan
| > | |
| > | | On 27 Jul 2012, at 12:37, Dale Henrichs wrote:
| > | |
| > | | > Johan,
| > | | >
| > | | > I've finally got the Metacello preview loading into pharo-1.4
| > | | > and
| > | | > behaving reasonably:) ...So you should be using
| > | | > ConfigurationOfMetacelloPreview-dkh.19 or later.
| > | | >
| > | | > Once you have ConfigurationOfMetacelloPreview-dkh.19 loaded
| > | | > the
| > | | > following expressions can be used to update to a later
| > | | > version
| > | | > (i.e., pick up bugfixes)
| > | | >
| > | | >    Metacello image
| > | | > configuration: #('MetacelloPreview');
| > | | > get.
| > | | >    Metacello image
| > | | > configuration: #('MetacelloPreview' );
| > | | > load.
| > | | >
| > | | > or:
| > | | >
| > | | >    Metacello image
| > | | > configuration: #('MetacelloPreview' );
| > | | > load: 'Tests'.
| > | | >
| > | | > to load up the tests as examples. Now that I've got Pharo-1.4
| > | | > working, I'll take a crack at making sure that the load runs
| > | | > cleanly for GemStone ...
| > | | >
| > | | > Dale
| > | | > ----- Original Message -----
| > | | > | From: "Johan Brichau" <[hidden email]>
| > | | > | To: "Dale Henrichs" <[hidden email]>
| > | | > | Cc: [hidden email]
| > | | > | Sent: Thursday, July 26, 2012 11:52:43 AM
| > | | > | Subject: Re: metacello diamond project dependency problem
| > | | > |
| > | | > | Forgot: using pharo14 and gs24.  So that should work
| > | | > |
| > | | > |
| > | | > | Johan (sent from my mobile)
| > | | > |
| > | | > | On 26 Jul 2012, at 19:16, Dale Henrichs
| > | | > | <[hidden email]>
| > | | > | wrote:
| > | | > |
| > | | > | > Johan,
| > | | > | >
| > | | > | > Sorry about the metacello group membership thing ... I
| > | | > | > had
| > | | > | > gotten a
| > | | > | > gmail account a while back and then I (unfortunately)
| > | | > | > joined
| > | | > | > g+
| > | | > | > and then google insisted that the gmail account be used
| > | | > | > for
| > | | > | > logging in and then magically all of the notification
| > | | > | > mail
| > | | > | > that
| > | | > | > I
| > | | > | > had carefully configured to come to my vmware mailbox has
| > | | > | > been
| > | | > | > sent to my gmail account (which I never use) ... I'm not
| > | | > | > sure
| > | | > | > when
| > | | > | > this happened and I only noticed recently that I wasn't
| > | | > | > receiving
| > | | > | > mail that I expected to be getting (like metacello
| > | | > | > membership
| > | | > | > pending) ... I've cc'd the metacello list so we can
| > | | > | > continue
| > | | > | > the
| > | | > | > conversation there..
| > | | > | >
| > | | > | > Two things:
| > | | > | >
| > | | > | >  1. the fetching old versions of packages does happen ...
| > | | > | >  they
| > | | > | >  are
| > | | > | >  not _loaded_ but they
| > | | > | >     do get fetched ... this would be a tough nut to crack
| > | | > | >     with
| > | | > | >     the
| > | | > | >     current version
| > | | > | >     of Metacello
| > | | > | >  2. I'm about to release (today or tomorrow) a
| > | | > | >  pre-release
| > | | > | >  version
| > | | > | >  of Metacello that
| > | | > | >     introduces a scripting API that is intended to allow
| > | | > | >     you
| > | | > | >     to
| > | | > | >     "pin" projects to a
| > | | > | >     particular version (without editting configs) and no
| > | | > | >     fetching
| > | | > | >     of packages from
| > | | > | >     older versions will occur .... so you'd be the
| > | | > | >     "perfect
| > | | > | >     test
| > | | > | >     case".
| > | | > | >
| > | | > | > This pre-release version of Metacello should not have any
| > | | > | > behavior
| > | | > | > differences from the current released version of
| > | | > | > Metacello
| > | | > | > with
| > | | > | > the exception of the addition of git/github support
| > | | > | > (which
| > | | > | > you
| > | | > | > don't need) and the scripting api (which you do).
| > | | > | >
| > | | > | > So if you are willing I'd like you to attempt to use the
| > | | > | > pre-release version of Metacello to get your job done ...
| > | | > | > I'm
| > | | > | > more
| > | | > | > than willing to commit to fixing bugs and tweak features
| > | | > | > so
| > | | > | > that
| > | | > | > you can get Metacello to work for you ...
| > | | > | >
| > | | > | > I am suggesting that you use the pre-release because the
| > | | > | > intent
| > | | > | > of
| > | | > | > the features that I've added to the scripting api is to:
| > | | > | >
| > | | > | >  be able to tell metacello to explicitly load a
| > | | > | >  certain version of a project _regardless_ of what a
| > | | > | >  dependent
| > | | > | >  project's configuration has to say about that.
| > | | > | >
| > | | > | > There are actually two features of the API that come into
| > | | > | > play:
| > | | > | >
| > | | > | >  1. the project registry
| > | | > | >  2. the ability to customize upgrades/downgrades
| > | | > | >
| > | | > | > The project registry records the projectSpecs that you
| > | | > | > used
| > | | > | > when
| > | | > | > loading the image ... so the api knows exactly what you
| > | | > | > loaded.
| > | | > | > You can add a specification to the registry BEFORE the
| > | | > | > project
| > | | > | > is
| > | | > | > actually loaded so that when a project has that project
| > | | > | > as a
| > | | > | > dependency the version in the registry will be used. You
| > | | > | > can
| > | | > | > lock
| > | | > | > project registrations so that an error will be thrown if
| > | | > | > an
| > | | > | > attempt is made to load a different version of the
| > | | > | > specified
| > | | > | > project.
| > | | > | >
| > | | > | > The customization comes into play when you hit a load
| > | | > | > expression
| > | | > | > that causes a lock error or that you know will do
| > | | > | > something
| > | | > | > you
| > | | > | > don't want...for every project upgrade/downgrade during a
| > | | > | > load,
| > | | > | > you have the opportunity `allow` or `disallow` the
| > | | > | > action. By
| > | | > | > default upgrades are allowed and downgrades are
| > | | > | > disallowed,
| > | | > | > but
| > | | > | > you can specify your own rules ...
| > | | > | >
| > | | > | > In your case you will want to `lock` Seaside to a
| > | | > | > particular
| > | | > | > version and repository:
| > | | > | >
| > | | > | >  Metacello new
| > | | > | >    configuration: 'Seaside30';
| > | | > | >    version: '3.0.7.1';
| > | | > | >    repository: '<repository description for your override
| > | | > | >    repository>';
| > | | > | >    lock.
| > | | > | >
| > | | > | > Then when you load Seaside-Testing you use the api to
| > | | > | > deny
| > | | > | > upgrades/downgrades for Seaside30 and bypass lock
| > | | > | > violation
| > | | > | > errors:
| > | | > | >
| > | | > | >  Metacello new
| > | | > | >    configuration: 'Seaside-Testing';
| > | | > | >    version: #stable;
| > | | > | >    repository: '<repositiory description for
| > | | > | >    Seaside-Testing
| > | | > | >    config>';
| > | | > | >    onUpgrade: [:ex :existing :new |
| > | | > | >      new baseName = 'Seaside30
| > | | > | >        ifTrue: [ ex disallow ].
| > | | > | >      ex pass];
| > | | > | >    onDowngrade: [:ex :existing :new |
| > | | > | >      new baseName = 'Seaside30
| > | | > | >        ifTrue: [ ex disallow ].
| > | | > | >      ex pass]
| > | | > | >    load.
| > | | > | >
| > | | > | > Technically you can probably get by without the
| > | | > | > onUpgrade:
| > | | > | > onDowngrade: blocks in this case, because the
| > | | > | > pre-registration
| > | | > | > of
| > | | > | > Seaside30 should cause Seaside-Testing to use 3.0.7.1
| > | | > | > instead
| > | | > | > of
| > | | > | > 3.0.0-rc.2...
| > | | > | >
| > | | > | > So if you are willing to be a guinea pig, give me the
| > | | > | > particulars
| > | | > | > of the version of pharo that you are using (pharo-1.3 and
| > | | > | > pharo-1.4 are known to work ... pharo-2.0 has issues and
| > | | > | > I
| > | | > | > just
| > | | > | > haven't tried pharo-1.2 and earlier versions yet ... it
| > | | > | > also
| > | | > | > known
| > | | > | > to work on Squeak4.3, GemStone2.4 and GemStone3.1) and if
| > | | > | > you're
| > | | > | > using something other that 1.3 or 1.4 I'll ensure that
| > | | > | > the
| > | | > | > api
| > | | > | > works there.
| > | | > | >
| > | | > | > So what do you think?
| > | | > | >
| > | | > | > Dale
| > | | > | >
| > | | > | > [1]
| > | | > | > http://code.google.com/p/metacello/issues/detail?id=150
| > | | > | > ----- Original Message -----
| > | | > | > | From: "Johan Brichau" <[hidden email]>
| > | | > | > | To: "Dale Henrichs" <[hidden email]>
| > | | > | > | Sent: Thursday, July 26, 2012 8:18:22 AM
| > | | > | > | Subject: metacello diamond project dependency problem
| > | | > | > |
| > | | > | > | Hi Dale,
| > | | > | > |
| > | | > | > | I wanted to send this to the metacello group, but I do
| > | | > | > | not
| > | | > | > | have
| > | | > | > | access (yet).
| > | | > | > | Since I'm stuck with it, I thought to ask you directly
| > | | > | > | already.
| > | | > | > |
| > | | > | > | I have a problem with diamond project dependencies in
| > | | > | > | metacello:
| > | | > | > |
| > | | > | > | YesPlan explicitly requires Seaside 3.0.7.1
| > | | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| > | | > | > | Seaside-Testing explicitly requires Seaside 3.0.0-rc.2
| > | | > | > |
| > | | > | > | All project dependencies use the (default) version
| > | | > | > | operator
| > | | > | > | (#>=)
| > | | > | > |
| > | | > | > | Launching the load eventually triggers fetch operations
| > | | > | > | for
| > | | > | > | packages
| > | | > | > | of Seaside 3.0.0-rc.2.
| > | | > | > | However, I do not want this version of Seaside to load.
| > | | > | > | I
| > | | > | > | want
| > | | > | > | the
| > | | > | > | version specified in my Yesplan config.
| > | | > | > |
| > | | > | > | I have similar problems in the inverse direction: i.e.
| > | | > | > | when
| > | | > | > | I
| > | | > | > | update
| > | | > | > | the Seaside-Testing configuration to require the
| > | | > | > | #stable
| > | | > | > | Seaside
| > | | > | > | version, it tries to fetch packages for a more recent
| > | | > | > | Seaside
| > | | > | > | version than I want to (i.e. for an older version of
| > | | > | > | Yesplan):
| > | | > | > |
| > | | > | > | YesPlan explicitly requires Seaside 3.0.6.4
| > | | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| > | | > | > | Seaside-Testing explicitly requires Seaside #stable
| > | | > | > |
| > | | > | > | It seems I want to be able to tell metacello to
| > | | > | > | explicitly
| > | | > | > | load a
| > | | > | > | certain version of a project _regardless_ of what a
| > | | > | > | dependent
| > | | > | > | project's configuration has to say about that.
| > | | > | > |
| > | | > | > | The issue is that I want to protect my load from using
| > | | > | > | any
| > | | > | > | packages
| > | | > | > | that I did not replicate to my local repository (I'm
| > | | > | > | using
| > | | > | > | a
| > | | > | > | #repositoryOverrides: during the load). Now, with the
| > | | > | > | first
| > | | > | > | situation above, I would have expected that the
| > | | > | > | dependency
| > | | > | > | of
| > | | > | > | SeasideTesting on an older version of Seaside would
| > | | > | > | have
| > | | > | > | been
| > | | > | > | ignored. However, it's trying to fetch old packages
| > | | > | > | which I
| > | | > | > | do
| > | | > | > | not
| > | | > | > | have on my local repository. For the second situation,
| > | | > | > | I
| > | | > | > | did
| > | | > | > | expect
| > | | > | > | the problem but nevertheless I would like to avoid it.
| > | | > | > |
| > | | > | > | In general, this is a problem I experience frequently:
| > | | > | > | some
| > | | > | > | project's
| > | | > | > | #stable version moved up a version but I do not want to
| > | | > | > | follow
| > | | > | > | that
| > | | > | > | upgrade. Is it possible to do that without manually
| > | | > | > | fixing
| > | | > | > | the
| > | | > | > | configuration file in each of the configurations I
| > | | > | > | include?
| > | | > | > |
| > | | > | > | I hope you can make sense of my question ;-)
| > | | > | > |
| > | | > | > | Johan
| > | | > |
| > | |
| > | |
| > |
|
|

Hi Dale,

Thanks for the hard night work: it's working great for me.
I currently only tested in Pharo. A load in GS will follow shortly but I still need to upgrade GLASS first as well.

Both the explicit locking of a project version and the #onUpgrade: #onDownGrade: options work just fine.
I see a lot of possibilities to simply my 'package manipulation' scripts where I have been using Gofer and Metacello before. I'll give those a try later on. The primary use for me right now is the explicit locking: I have been struggling with such problems for a long time. So that's really useful.

As you already noticed, I miss the possibility to pass a login/pass everywhere you can specify a repository url. Because our dev repositories are password protected, I need to pass those to Metacello. For now, I circumvent the problem by adding the repositories to my default MC repositories group (see my load script below) before launching the actually Metacello load. That seemed to work. Because of this problem I also need to load the ConfigurationOfNextPlan package using Gofer before I can launch the new Metacello load script.

I think it might be a good idea to allow to pass MCRepository instances everywhere where you can pass a repository string. That would make it transparent and does not require additional API methods for urls with login/pass.

--- Yesplan load script below ----

"Get all development repository instances"
repos := self devRepositories.
"Add the Pharo-specific replication repo"
repos add: (MCHttpRepository
                                        location: 'http://devserver/replication'
                                        user: Username
                                        password: Pasword).
"Add the repos to the default MC group to make metacello load work with user/pass"
repos do:[:r | MCRepositoryGroup default addRepository: r].
"Load with metacello script API"
Metacello new
    configuration: 'NextPlan';
  version: '1.5.0-baseline';
    repository: 'http://devserver/nextplan-trunk';
  repositoryOverrides: #('http://devserver/replication' 'http://devserver/nextplan-trunk' 'http://devserver/common' 'http://devserver/SeasideDynamicSVG' 'http://devserver/jqwidgetbox' 'http://ss3.gemstone.com/ss/Parasol');
    onUpgrade: [:ex :existing :new |
      new baseName = 'Seaside30' ifTrue: [ ex disallow ].
    ex pass];
  onDowngrade: [:ex :existing :new |
                                                new baseName = 'Seaside30' ifTrue: [ ex disallow ].
      ex pass];  
  load: 'NextPlan-Dev'.

On 27 Jul 2012, at 14:27, Dale Henrichs wrote:

----- Original Message -----
| From: "Johan Brichau" <[hidden email]>
| To: "Dale Henrichs" <[hidden email]>
| Cc: [hidden email]
| Sent: Saturday, July 28, 2012 3:15:31 AM
| Subject: Re: metacello diamond project dependency problem
|
| Hi Dale,
|
| Thanks for the hard night work: it's working great for me.

Good I'm glad to hear that:) I'll let my wife know that you appreciated my effort:)

| I currently only tested in Pharo. A load in GS will follow shortly
| but I still need to upgrade GLASS first as well.

Speaking of GS, I can see that be nice to add some gemstone-specific options to the api like `autoCommit` or `bulkMigrate`....

|
| Both the explicit locking of a project version and the #onUpgrade:
| #onDownGrade: options work just fine.
| I see a lot of possibilities to simply my 'package manipulation'
| scripts where I have been using Gofer and Metacello before. I'll

Yes, I agree that there are some interesting possibilities there and I'm open to the possibilities and I'll definitely be willing to add new elements to the api if it will help simplify operations ...

| give those a try later on. The primary use for me right now is the
| explicit locking: I have been struggling with such problems for a
| long time. So that's really useful.

I'd been aware of that type of problem for awhile, but didn't have any good solutions. I "discovered" the locking notion by looking at jam[1], a package manager for node.js, and thought it would fit well with what I wanted to do and I'm glad to see that it's fitting your need as well.

[1] http://jamjs.org/docs
|
| As you already noticed, I miss the possibility to pass a login/pass
| everywhere you can specify a repository url. Because our dev
| repositories are password protected, I need to pass those to
| Metacello. For now, I circumvent the problem by adding the
| repositories to my default MC repositories group (see my load script
| below) before launching the actually Metacello load. That seemed to
| work. Because of this problem I also need to load the
| ConfigurationOfNextPlan package using Gofer before I can launch the
| new Metacello load script.
|
| I think it might be a good idea to allow to pass MCRepository
| instances everywhere where you can pass a repository string. That
| would make it transparent and does not require additional API
| methods for urls with login/pass.

That's not a bad idea ... I agree that it is preferable to adding username:password: args in a bunch of places. We could also add some syntax to the repository description strings, but I'm not quite sure how to fit that in.... maybe:

  <a href="http://hostname:port:username:password/">http://hostname:port:username:password/...

Ah, but if you can use a live repository you can avoid having the username and password embedded in scripts ... so perhaps the live repository is the best option...but if you are creating live repos the username and pass will be embedded anyway so the string form isn't any worse and will cut down on the amount of code needed ...

What do you (and others) think:

  Can we get away with username/passwords in the repository
  description or do we need live references?

Live repo refs are superior to adding additional args, but perhaps username/pass in description string is superior to both?

|
| --- Yesplan load script below ----
|
| "Get all development repository instances"
| repos := self devRepositories.
| "Add the Pharo-specific replication repo"
| repos add: (MCHttpRepository
| location: 'http://devserver/replication'
| user: Username
| password: Pasword).
| "Add the repos to the default MC group to make metacello load work
| with user/pass"
| repos do:[:r | MCRepositoryGroup default addRepository: r].
| "Load with metacello script API"
| Metacello new
|     configuration: 'NextPlan';
|   version: '1.5.0-baseline';
|     repository: 'http://devserver/nextplan-trunk';
|   repositoryOverrides: #('http://devserver/replication'
|   'http://devserver/nextplan-trunk' 'http://devserver/common'
|   'http://devserver/SeasideDynamicSVG'
|   'http://devserver/jqwidgetbox'
|   'http://ss3.gemstone.com/ss/Parasol');
|     onUpgrade: [:ex :existing :new |
|       new baseName = 'Seaside30' ifTrue: [ ex disallow ].
|     ex pass];
|   onDowngrade: [:ex :existing :new |
| new baseName = 'Seaside30' ifTrue: [ ex disallow ].
|       ex pass];
|   load: 'NextPlan-Dev'.

Very cool ... add a autoCommit and bulkMigrate and the script would load NextPlan in GemStone, too!

|
| On 27 Jul 2012, at 14:27, Dale Henrichs wrote:
|
| > Haha, yeah sometimes you just have to just keep pushing hard... I
| > didn't get a chance to actually start until after dinner a meeting
| > took up most of the afternoon, and I got tired of delaying the
| > release ...
| >
| > ConfigurationOfMetacelloPreview-dkh.21 looks like it's in pretty
| > good shape... tests are green so I'll be calling it a night, errr
| > day.
| >
| > I'll be interested in seeing your load script and hearing what you
| > think ...
| >
| > I feel real good about the underlying foundation and implementation
| > and I like the basic API elements, but I do think that scripts can
| > be made even more compact.
| >
| > But right now is not the time to fine tune the api ... need to
| > understand which of the features are helping and which ones are
| > hindering...
| >
| > Dale
| >
| > ----- Original Message -----
| > | From: "Johan Brichau" <[hidden email]>
| > | To: "Dale Henrichs" <[hidden email]>
| > | Cc: [hidden email]
| > | Sent: Friday, July 27, 2012 5:14:03 AM
| > | Subject: Re: metacello diamond project dependency problem
| > |
| > | Hi Dale,
| > |
| > | Late night work? ;-)
| > |
| > | I'm making progress as well. It seems I can use it to address my
| > | problem because I got Yesplan to load correctly from the local
| > | repositories.
| > |
| > | I'll get back with my experiences
| > |
| > | On 27 Jul 2012, at 14:04, Dale Henrichs wrote:
| > |
| > | > The travis ci builds showed another problem and I'm now
| > | > addressing
| > | > the failing tests ... when travis runs clean I'll publish a new
| > | > version ... and let you know
| > | >
| > | > Dale
| > | >
| > | > ----- Original Message -----
| > | > | From: "Dale Henrichs" <[hidden email]>
| > | > | To: "Johan Brichau" <[hidden email]>
| > | > | Cc: [hidden email]
| > | > | Sent: Friday, July 27, 2012 5:01:37 AM
| > | > | Subject: Re: metacello diamond project dependency problem
| > | > |
| > | > | GemStone should load up and work as well ... start with GLASS
| > | > | 1.0-beta.8.7.2 and run the install script ...
| > | > |
| > | > | ----- Original Message -----
| > | > | | From: "Johan Brichau" <[hidden email]>
| > | > | | To: "Dale Henrichs" <[hidden email]>
| > | > | | Cc: [hidden email]
| > | > | | Sent: Friday, July 27, 2012 3:47:08 AM
| > | > | | Subject: Re: metacello diamond project dependency problem
| > | > | |
| > | > | | Hi Dale,
| > | > | |
| > | > | | Thanks.
| > | > | |
| > | > | | I'm playing with it right now.
| > | > | |
| > | > | | Maybe some quick questions already:
| > | > | |
| > | > | | - is there a way to communicatie login & pass with a
| > | > | | repository
| > | > | | ?
| > | > | |  
| > | > | | - running the snippet below gives me the error that
| > | > | | Metacello-Base
| > | > | | cannot be resolved (although it's even loaded already):
| > | > | |
| > | > | |  Metacello image
| > | > | |    baseline: 'Metacello';
| > | > | |    load: 'Tests'.
| > | > | |
| > | > | | Maybe I should check out the changes you made right now?
| > | > | | ;-)
| > | > | |
| > | > | | Johan
| > | > | |
| > | > | | On 27 Jul 2012, at 12:37, Dale Henrichs wrote:
| > | > | |
| > | > | | > Johan,
| > | > | | >
| > | > | | > I've finally got the Metacello preview loading into
| > | > | | > pharo-1.4
| > | > | | > and
| > | > | | > behaving reasonably:) ...So you should be using
| > | > | | > ConfigurationOfMetacelloPreview-dkh.19 or later.
| > | > | | >
| > | > | | > Once you have ConfigurationOfMetacelloPreview-dkh.19
| > | > | | > loaded
| > | > | | > the
| > | > | | > following expressions can be used to update to a later
| > | > | | > version
| > | > | | > (i.e., pick up bugfixes)
| > | > | | >
| > | > | | >    Metacello image
| > | > | | > configuration: #('MetacelloPreview');
| > | > | | > get.
| > | > | | >    Metacello image
| > | > | | > configuration: #('MetacelloPreview' );
| > | > | | > load.
| > | > | | >
| > | > | | > or:
| > | > | | >
| > | > | | >    Metacello image
| > | > | | > configuration: #('MetacelloPreview' );
| > | > | | > load: 'Tests'.
| > | > | | >
| > | > | | > to load up the tests as examples. Now that I've got
| > | > | | > Pharo-1.4
| > | > | | > working, I'll take a crack at making sure that the load
| > | > | | > runs
| > | > | | > cleanly for GemStone ...
| > | > | | >
| > | > | | > Dale
| > | > | | > ----- Original Message -----
| > | > | | > | From: "Johan Brichau" <[hidden email]>
| > | > | | > | To: "Dale Henrichs" <[hidden email]>
| > | > | | > | Cc: [hidden email]
| > | > | | > | Sent: Thursday, July 26, 2012 11:52:43 AM
| > | > | | > | Subject: Re: metacello diamond project dependency
| > | > | | > | problem
| > | > | | > |
| > | > | | > | Forgot: using pharo14 and gs24.  So that should work
| > | > | | > |
| > | > | | > |
| > | > | | > | Johan (sent from my mobile)
| > | > | | > |
| > | > | | > | On 26 Jul 2012, at 19:16, Dale Henrichs
| > | > | | > | <[hidden email]>
| > | > | | > | wrote:
| > | > | | > |
| > | > | | > | > Johan,
| > | > | | > | >
| > | > | | > | > Sorry about the metacello group membership thing ...
| > | > | | > | > I
| > | > | | > | > had
| > | > | | > | > gotten a
| > | > | | > | > gmail account a while back and then I (unfortunately)
| > | > | | > | > joined
| > | > | | > | > g+
| > | > | | > | > and then google insisted that the gmail account be
| > | > | | > | > used
| > | > | | > | > for
| > | > | | > | > logging in and then magically all of the notification
| > | > | | > | > mail
| > | > | | > | > that
| > | > | | > | > I
| > | > | | > | > had carefully configured to come to my vmware mailbox
| > | > | | > | > has
| > | > | | > | > been
| > | > | | > | > sent to my gmail account (which I never use) ... I'm
| > | > | | > | > not
| > | > | | > | > sure
| > | > | | > | > when
| > | > | | > | > this happened and I only noticed recently that I
| > | > | | > | > wasn't
| > | > | | > | > receiving
| > | > | | > | > mail that I expected to be getting (like metacello
| > | > | | > | > membership
| > | > | | > | > pending) ... I've cc'd the metacello list so we can
| > | > | | > | > continue
| > | > | | > | > the
| > | > | | > | > conversation there..
| > | > | | > | >
| > | > | | > | > Two things:
| > | > | | > | >
| > | > | | > | >  1. the fetching old versions of packages does happen
| > | > | | > | >  ...
| > | > | | > | >  they
| > | > | | > | >  are
| > | > | | > | >  not _loaded_ but they
| > | > | | > | >     do get fetched ... this would be a tough nut to
| > | > | | > | >     crack
| > | > | | > | >     with
| > | > | | > | >     the
| > | > | | > | >     current version
| > | > | | > | >     of Metacello
| > | > | | > | >  2. I'm about to release (today or tomorrow) a
| > | > | | > | >  pre-release
| > | > | | > | >  version
| > | > | | > | >  of Metacello that
| > | > | | > | >     introduces a scripting API that is intended to
| > | > | | > | >     allow
| > | > | | > | >     you
| > | > | | > | >     to
| > | > | | > | >     "pin" projects to a
| > | > | | > | >     particular version (without editting configs) and
| > | > | | > | >     no
| > | > | | > | >     fetching
| > | > | | > | >     of packages from
| > | > | | > | >     older versions will occur .... so you'd be the
| > | > | | > | >     "perfect
| > | > | | > | >     test
| > | > | | > | >     case".
| > | > | | > | >
| > | > | | > | > This pre-release version of Metacello should not have
| > | > | | > | > any
| > | > | | > | > behavior
| > | > | | > | > differences from the current released version of
| > | > | | > | > Metacello
| > | > | | > | > with
| > | > | | > | > the exception of the addition of git/github support
| > | > | | > | > (which
| > | > | | > | > you
| > | > | | > | > don't need) and the scripting api (which you do).
| > | > | | > | >
| > | > | | > | > So if you are willing I'd like you to attempt to use
| > | > | | > | > the
| > | > | | > | > pre-release version of Metacello to get your job done
| > | > | | > | > ...
| > | > | | > | > I'm
| > | > | | > | > more
| > | > | | > | > than willing to commit to fixing bugs and tweak
| > | > | | > | > features
| > | > | | > | > so
| > | > | | > | > that
| > | > | | > | > you can get Metacello to work for you ...
| > | > | | > | >
| > | > | | > | > I am suggesting that you use the pre-release because
| > | > | | > | > the
| > | > | | > | > intent
| > | > | | > | > of
| > | > | | > | > the features that I've added to the scripting api is
| > | > | | > | > to:
| > | > | | > | >
| > | > | | > | >  be able to tell metacello to explicitly load a
| > | > | | > | >  certain version of a project _regardless_ of what a
| > | > | | > | >  dependent
| > | > | | > | >  project's configuration has to say about that.
| > | > | | > | >
| > | > | | > | > There are actually two features of the API that come
| > | > | | > | > into
| > | > | | > | > play:
| > | > | | > | >
| > | > | | > | >  1. the project registry
| > | > | | > | >  2. the ability to customize upgrades/downgrades
| > | > | | > | >
| > | > | | > | > The project registry records the projectSpecs that
| > | > | | > | > you
| > | > | | > | > used
| > | > | | > | > when
| > | > | | > | > loading the image ... so the api knows exactly what
| > | > | | > | > you
| > | > | | > | > loaded.
| > | > | | > | > You can add a specification to the registry BEFORE
| > | > | | > | > the
| > | > | | > | > project
| > | > | | > | > is
| > | > | | > | > actually loaded so that when a project has that
| > | > | | > | > project
| > | > | | > | > as a
| > | > | | > | > dependency the version in the registry will be used.
| > | > | | > | > You
| > | > | | > | > can
| > | > | | > | > lock
| > | > | | > | > project registrations so that an error will be thrown
| > | > | | > | > if
| > | > | | > | > an
| > | > | | > | > attempt is made to load a different version of the
| > | > | | > | > specified
| > | > | | > | > project.
| > | > | | > | >
| > | > | | > | > The customization comes into play when you hit a load
| > | > | | > | > expression
| > | > | | > | > that causes a lock error or that you know will do
| > | > | | > | > something
| > | > | | > | > you
| > | > | | > | > don't want...for every project upgrade/downgrade
| > | > | | > | > during a
| > | > | | > | > load,
| > | > | | > | > you have the opportunity `allow` or `disallow` the
| > | > | | > | > action. By
| > | > | | > | > default upgrades are allowed and downgrades are
| > | > | | > | > disallowed,
| > | > | | > | > but
| > | > | | > | > you can specify your own rules ...
| > | > | | > | >
| > | > | | > | > In your case you will want to `lock` Seaside to a
| > | > | | > | > particular
| > | > | | > | > version and repository:
| > | > | | > | >
| > | > | | > | >  Metacello new
| > | > | | > | >    configuration: 'Seaside30';
| > | > | | > | >    version: '3.0.7.1';
| > | > | | > | >    repository: '<repository description for your
| > | > | | > | >    override
| > | > | | > | >    repository>';
| > | > | | > | >    lock.
| > | > | | > | >
| > | > | | > | > Then when you load Seaside-Testing you use the api to
| > | > | | > | > deny
| > | > | | > | > upgrades/downgrades for Seaside30 and bypass lock
| > | > | | > | > violation
| > | > | | > | > errors:
| > | > | | > | >
| > | > | | > | >  Metacello new
| > | > | | > | >    configuration: 'Seaside-Testing';
| > | > | | > | >    version: #stable;
| > | > | | > | >    repository: '<repositiory description for
| > | > | | > | >    Seaside-Testing
| > | > | | > | >    config>';
| > | > | | > | >    onUpgrade: [:ex :existing :new |
| > | > | | > | >      new baseName = 'Seaside30
| > | > | | > | >        ifTrue: [ ex disallow ].
| > | > | | > | >      ex pass];
| > | > | | > | >    onDowngrade: [:ex :existing :new |
| > | > | | > | >      new baseName = 'Seaside30
| > | > | | > | >        ifTrue: [ ex disallow ].
| > | > | | > | >      ex pass]
| > | > | | > | >    load.
| > | > | | > | >
| > | > | | > | > Technically you can probably get by without the
| > | > | | > | > onUpgrade:
| > | > | | > | > onDowngrade: blocks in this case, because the
| > | > | | > | > pre-registration
| > | > | | > | > of
| > | > | | > | > Seaside30 should cause Seaside-Testing to use 3.0.7.1
| > | > | | > | > instead
| > | > | | > | > of
| > | > | | > | > 3.0.0-rc.2...
| > | > | | > | >
| > | > | | > | > So if you are willing to be a guinea pig, give me the
| > | > | | > | > particulars
| > | > | | > | > of the version of pharo that you are using (pharo-1.3
| > | > | | > | > and
| > | > | | > | > pharo-1.4 are known to work ... pharo-2.0 has issues
| > | > | | > | > and
| > | > | | > | > I
| > | > | | > | > just
| > | > | | > | > haven't tried pharo-1.2 and earlier versions yet ...
| > | > | | > | > it
| > | > | | > | > also
| > | > | | > | > known
| > | > | | > | > to work on Squeak4.3, GemStone2.4 and GemStone3.1)
| > | > | | > | > and if
| > | > | | > | > you're
| > | > | | > | > using something other that 1.3 or 1.4 I'll ensure
| > | > | | > | > that
| > | > | | > | > the
| > | > | | > | > api
| > | > | | > | > works there.
| > | > | | > | >
| > | > | | > | > So what do you think?
| > | > | | > | >
| > | > | | > | > Dale
| > | > | | > | >
| > | > | | > | > [1]
| > | > | | > | > http://code.google.com/p/metacello/issues/detail?id=150
| > | > | | > | > ----- Original Message -----
| > | > | | > | > | From: "Johan Brichau" <[hidden email]>
| > | > | | > | > | To: "Dale Henrichs" <[hidden email]>
| > | > | | > | > | Sent: Thursday, July 26, 2012 8:18:22 AM
| > | > | | > | > | Subject: metacello diamond project dependency
| > | > | | > | > | problem
| > | > | | > | > |
| > | > | | > | > | Hi Dale,
| > | > | | > | > |
| > | > | | > | > | I wanted to send this to the metacello group, but I
| > | > | | > | > | do
| > | > | | > | > | not
| > | > | | > | > | have
| > | > | | > | > | access (yet).
| > | > | | > | > | Since I'm stuck with it, I thought to ask you
| > | > | | > | > | directly
| > | > | | > | > | already.
| > | > | | > | > |
| > | > | | > | > | I have a problem with diamond project dependencies
| > | > | | > | > | in
| > | > | | > | > | metacello:
| > | > | | > | > |
| > | > | | > | > | YesPlan explicitly requires Seaside 3.0.7.1
| > | > | | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| > | > | | > | > | Seaside-Testing explicitly requires Seaside
| > | > | | > | > | 3.0.0-rc.2
| > | > | | > | > |
| > | > | | > | > | All project dependencies use the (default) version
| > | > | | > | > | operator
| > | > | | > | > | (#>=)
| > | > | | > | > |
| > | > | | > | > | Launching the load eventually triggers fetch
| > | > | | > | > | operations
| > | > | | > | > | for
| > | > | | > | > | packages
| > | > | | > | > | of Seaside 3.0.0-rc.2.
| > | > | | > | > | However, I do not want this version of Seaside to
| > | > | | > | > | load.
| > | > | | > | > | I
| > | > | | > | > | want
| > | > | | > | > | the
| > | > | | > | > | version specified in my Yesplan config.
| > | > | | > | > |
| > | > | | > | > | I have similar problems in the inverse direction:
| > | > | | > | > | i.e.
| > | > | | > | > | when
| > | > | | > | > | I
| > | > | | > | > | update
| > | > | | > | > | the Seaside-Testing configuration to require the
| > | > | | > | > | #stable
| > | > | | > | > | Seaside
| > | > | | > | > | version, it tries to fetch packages for a more
| > | > | | > | > | recent
| > | > | | > | > | Seaside
| > | > | | > | > | version than I want to (i.e. for an older version
| > | > | | > | > | of
| > | > | | > | > | Yesplan):
| > | > | | > | > |
| > | > | | > | > | YesPlan explicitly requires Seaside 3.0.6.4
| > | > | | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| > | > | | > | > | Seaside-Testing explicitly requires Seaside #stable
| > | > | | > | > |
| > | > | | > | > | It seems I want to be able to tell metacello to
| > | > | | > | > | explicitly
| > | > | | > | > | load a
| > | > | | > | > | certain version of a project _regardless_ of what a
| > | > | | > | > | dependent
| > | > | | > | > | project's configuration has to say about that.
| > | > | | > | > |
| > | > | | > | > | The issue is that I want to protect my load from
| > | > | | > | > | using
| > | > | | > | > | any
| > | > | | > | > | packages
| > | > | | > | > | that I did not replicate to my local repository
| > | > | | > | > | (I'm
| > | > | | > | > | using
| > | > | | > | > | a
| > | > | | > | > | #repositoryOverrides: during the load). Now, with
| > | > | | > | > | the
| > | > | | > | > | first
| > | > | | > | > | situation above, I would have expected that the
| > | > | | > | > | dependency
| > | > | | > | > | of
| > | > | | > | > | SeasideTesting on an older version of Seaside would
| > | > | | > | > | have
| > | > | | > | > | been
| > | > | | > | > | ignored. However, it's trying to fetch old packages
| > | > | | > | > | which I
| > | > | | > | > | do
| > | > | | > | > | not
| > | > | | > | > | have on my local repository. For the second
| > | > | | > | > | situation,
| > | > | | > | > | I
| > | > | | > | > | did
| > | > | | > | > | expect
| > | > | | > | > | the problem but nevertheless I would like to avoid
| > | > | | > | > | it.
| > | > | | > | > |
| > | > | | > | > | In general, this is a problem I experience
| > | > | | > | > | frequently:
| > | > | | > | > | some
| > | > | | > | > | project's
| > | > | | > | > | #stable version moved up a version but I do not
| > | > | | > | > | want to
| > | > | | > | > | follow
| > | > | | > | > | that
| > | > | | > | > | upgrade. Is it possible to do that without manually
| > | > | | > | > | fixing
| > | > | | > | > | the
| > | > | | > | > | configuration file in each of the configurations I
| > | > | | > | > | include?
| > | > | | > | > |
| > | > | | > | > | I hope you can make sense of my question ;-)
| > | > | | > | > |
| > | > | | > | > | Johan
| > | > | | > |
| > | > | |
| > | > | |
| > | > |
| > |
| > |
|
|

RE: specifying username/password, there is a Metacello issue[1] with some more discussion about addressing the issue...

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

----- Original Message -----
| From: "Dale Henrichs" <[hidden email]>
| To: "Johan Brichau" <[hidden email]>
| Cc: [hidden email]
| Sent: Saturday, July 28, 2012 9:59:44 AM
| Subject: Re: metacello diamond project dependency problem
|
|
|
| ----- Original Message -----
| | From: "Johan Brichau" <[hidden email]>
| | To: "Dale Henrichs" <[hidden email]>
| | Cc: [hidden email]
| | Sent: Saturday, July 28, 2012 3:15:31 AM
| | Subject: Re: metacello diamond project dependency problem
| |
| | Hi Dale,
| |
| | Thanks for the hard night work: it's working great for me.
|
| Good I'm glad to hear that:) I'll let my wife know that you
| appreciated my effort:)
|
| | I currently only tested in Pharo. A load in GS will follow shortly
| | but I still need to upgrade GLASS first as well.
|
| Speaking of GS, I can see that be nice to add some gemstone-specific
| options to the api like `autoCommit` or `bulkMigrate`....
|
| |
| | Both the explicit locking of a project version and the #onUpgrade:
| | #onDownGrade: options work just fine.
| | I see a lot of possibilities to simply my 'package manipulation'
| | scripts where I have been using Gofer and Metacello before. I'll
|
| Yes, I agree that there are some interesting possibilities there and
| I'm open to the possibilities and I'll definitely be willing to add
| new elements to the api if it will help simplify operations ...
|
| | give those a try later on. The primary use for me right now is the
| | explicit locking: I have been struggling with such problems for a
| | long time. So that's really useful.
|
| I'd been aware of that type of problem for awhile, but didn't have
| any good solutions. I "discovered" the locking notion by looking at
| jam[1], a package manager for node.js, and thought it would fit well
| with what I wanted to do and I'm glad to see that it's fitting your
| need as well.
|
| [1] http://jamjs.org/docs
| |
| | As you already noticed, I miss the possibility to pass a login/pass
| | everywhere you can specify a repository url. Because our dev
| | repositories are password protected, I need to pass those to
| | Metacello. For now, I circumvent the problem by adding the
| | repositories to my default MC repositories group (see my load
| | script
| | below) before launching the actually Metacello load. That seemed to
| | work. Because of this problem I also need to load the
| | ConfigurationOfNextPlan package using Gofer before I can launch the
| | new Metacello load script.
| |
| | I think it might be a good idea to allow to pass MCRepository
| | instances everywhere where you can pass a repository string. That
| | would make it transparent and does not require additional API
| | methods for urls with login/pass.
|
| That's not a bad idea ... I agree that it is preferable to adding
| username:password: args in a bunch of places. We could also add some
| syntax to the repository description strings, but I'm not quite sure
| how to fit that in.... maybe:
|
|   <a href="http://hostname:port:username:password/">http://hostname:port:username:password/...
|
| Ah, but if you can use a live repository you can avoid having the
| username and password embedded in scripts ... so perhaps the live
| repository is the best option...but if you are creating live repos
| the username and pass will be embedded anyway so the string form
| isn't any worse and will cut down on the amount of code needed ...
|
| What do you (and others) think:
|
|   Can we get away with username/passwords in the repository
|   description or do we need live references?
|
| Live repo refs are superior to adding additional args, but perhaps
| username/pass in description string is superior to both?
|
| |
| | --- Yesplan load script below ----
| |
| | "Get all development repository instances"
| | repos := self devRepositories.
| | "Add the Pharo-specific replication repo"
| | repos add: (MCHttpRepository
| | location: 'http://devserver/replication'
| | user: Username
| | password: Pasword).
| | "Add the repos to the default MC group to make metacello load work
| | with user/pass"
| | repos do:[:r | MCRepositoryGroup default addRepository: r].
| | "Load with metacello script API"
| | Metacello new
| |     configuration: 'NextPlan';
| |   version: '1.5.0-baseline';
| |     repository: 'http://devserver/nextplan-trunk';
| |   repositoryOverrides: #('http://devserver/replication'
| |   'http://devserver/nextplan-trunk' 'http://devserver/common'
| |   'http://devserver/SeasideDynamicSVG'
| |   'http://devserver/jqwidgetbox'
| |   'http://ss3.gemstone.com/ss/Parasol');
| |     onUpgrade: [:ex :existing :new |
| |       new baseName = 'Seaside30' ifTrue: [ ex disallow ].
| |     ex pass];
| |   onDowngrade: [:ex :existing :new |
| | new baseName = 'Seaside30' ifTrue: [ ex disallow ].
| |       ex pass];
| |   load: 'NextPlan-Dev'.
|
| Very cool ... add a autoCommit and bulkMigrate and the script would
| load NextPlan in GemStone, too!
|
| |
| | On 27 Jul 2012, at 14:27, Dale Henrichs wrote:
| |
| | > Haha, yeah sometimes you just have to just keep pushing hard... I
| | > didn't get a chance to actually start until after dinner a
| | > meeting
| | > took up most of the afternoon, and I got tired of delaying the
| | > release ...
| | >
| | > ConfigurationOfMetacelloPreview-dkh.21 looks like it's in pretty
| | > good shape... tests are green so I'll be calling it a night, errr
| | > day.
| | >
| | > I'll be interested in seeing your load script and hearing what
| | > you
| | > think ...
| | >
| | > I feel real good about the underlying foundation and
| | > implementation
| | > and I like the basic API elements, but I do think that scripts
| | > can
| | > be made even more compact.
| | >
| | > But right now is not the time to fine tune the api ... need to
| | > understand which of the features are helping and which ones are
| | > hindering...
| | >
| | > Dale
| | >
| | > ----- Original Message -----
| | > | From: "Johan Brichau" <[hidden email]>
| | > | To: "Dale Henrichs" <[hidden email]>
| | > | Cc: [hidden email]
| | > | Sent: Friday, July 27, 2012 5:14:03 AM
| | > | Subject: Re: metacello diamond project dependency problem
| | > |
| | > | Hi Dale,
| | > |
| | > | Late night work? ;-)
| | > |
| | > | I'm making progress as well. It seems I can use it to address
| | > | my
| | > | problem because I got Yesplan to load correctly from the local
| | > | repositories.
| | > |
| | > | I'll get back with my experiences
| | > |
| | > | On 27 Jul 2012, at 14:04, Dale Henrichs wrote:
| | > |
| | > | > The travis ci builds showed another problem and I'm now
| | > | > addressing
| | > | > the failing tests ... when travis runs clean I'll publish a
| | > | > new
| | > | > version ... and let you know
| | > | >
| | > | > Dale
| | > | >
| | > | > ----- Original Message -----
| | > | > | From: "Dale Henrichs" <[hidden email]>
| | > | > | To: "Johan Brichau" <[hidden email]>
| | > | > | Cc: [hidden email]
| | > | > | Sent: Friday, July 27, 2012 5:01:37 AM
| | > | > | Subject: Re: metacello diamond project dependency problem
| | > | > |
| | > | > | GemStone should load up and work as well ... start with
| | > | > | GLASS
| | > | > | 1.0-beta.8.7.2 and run the install script ...
| | > | > |
| | > | > | ----- Original Message -----
| | > | > | | From: "Johan Brichau" <[hidden email]>
| | > | > | | To: "Dale Henrichs" <[hidden email]>
| | > | > | | Cc: [hidden email]
| | > | > | | Sent: Friday, July 27, 2012 3:47:08 AM
| | > | > | | Subject: Re: metacello diamond project dependency problem
| | > | > | |
| | > | > | | Hi Dale,
| | > | > | |
| | > | > | | Thanks.
| | > | > | |
| | > | > | | I'm playing with it right now.
| | > | > | |
| | > | > | | Maybe some quick questions already:
| | > | > | |
| | > | > | | - is there a way to communicatie login & pass with a
| | > | > | | repository
| | > | > | | ?
| | > | > | |  
| | > | > | | - running the snippet below gives me the error that
| | > | > | | Metacello-Base
| | > | > | | cannot be resolved (although it's even loaded already):
| | > | > | |
| | > | > | |  Metacello image
| | > | > | |    baseline: 'Metacello';
| | > | > | |    load: 'Tests'.
| | > | > | |
| | > | > | | Maybe I should check out the changes you made right now?
| | > | > | | ;-)
| | > | > | |
| | > | > | | Johan
| | > | > | |
| | > | > | | On 27 Jul 2012, at 12:37, Dale Henrichs wrote:
| | > | > | |
| | > | > | | > Johan,
| | > | > | | >
| | > | > | | > I've finally got the Metacello preview loading into
| | > | > | | > pharo-1.4
| | > | > | | > and
| | > | > | | > behaving reasonably:) ...So you should be using
| | > | > | | > ConfigurationOfMetacelloPreview-dkh.19 or later.
| | > | > | | >
| | > | > | | > Once you have ConfigurationOfMetacelloPreview-dkh.19
| | > | > | | > loaded
| | > | > | | > the
| | > | > | | > following expressions can be used to update to a later
| | > | > | | > version
| | > | > | | > (i.e., pick up bugfixes)
| | > | > | | >
| | > | > | | >    Metacello image
| | > | > | | > configuration: #('MetacelloPreview');
| | > | > | | > get.
| | > | > | | >    Metacello image
| | > | > | | > configuration: #('MetacelloPreview' );
| | > | > | | > load.
| | > | > | | >
| | > | > | | > or:
| | > | > | | >
| | > | > | | >    Metacello image
| | > | > | | > configuration: #('MetacelloPreview' );
| | > | > | | > load: 'Tests'.
| | > | > | | >
| | > | > | | > to load up the tests as examples. Now that I've got
| | > | > | | > Pharo-1.4
| | > | > | | > working, I'll take a crack at making sure that the load
| | > | > | | > runs
| | > | > | | > cleanly for GemStone ...
| | > | > | | >
| | > | > | | > Dale
| | > | > | | > ----- Original Message -----
| | > | > | | > | From: "Johan Brichau" <[hidden email]>
| | > | > | | > | To: "Dale Henrichs" <[hidden email]>
| | > | > | | > | Cc: [hidden email]
| | > | > | | > | Sent: Thursday, July 26, 2012 11:52:43 AM
| | > | > | | > | Subject: Re: metacello diamond project dependency
| | > | > | | > | problem
| | > | > | | > |
| | > | > | | > | Forgot: using pharo14 and gs24.  So that should work
| | > | > | | > |
| | > | > | | > |
| | > | > | | > | Johan (sent from my mobile)
| | > | > | | > |
| | > | > | | > | On 26 Jul 2012, at 19:16, Dale Henrichs
| | > | > | | > | <[hidden email]>
| | > | > | | > | wrote:
| | > | > | | > |
| | > | > | | > | > Johan,
| | > | > | | > | >
| | > | > | | > | > Sorry about the metacello group membership thing
| | > | > | | > | > ...
| | > | > | | > | > I
| | > | > | | > | > had
| | > | > | | > | > gotten a
| | > | > | | > | > gmail account a while back and then I
| | > | > | | > | > (unfortunately)
| | > | > | | > | > joined
| | > | > | | > | > g+
| | > | > | | > | > and then google insisted that the gmail account be
| | > | > | | > | > used
| | > | > | | > | > for
| | > | > | | > | > logging in and then magically all of the
| | > | > | | > | > notification
| | > | > | | > | > mail
| | > | > | | > | > that
| | > | > | | > | > I
| | > | > | | > | > had carefully configured to come to my vmware
| | > | > | | > | > mailbox
| | > | > | | > | > has
| | > | > | | > | > been
| | > | > | | > | > sent to my gmail account (which I never use) ...
| | > | > | | > | > I'm
| | > | > | | > | > not
| | > | > | | > | > sure
| | > | > | | > | > when
| | > | > | | > | > this happened and I only noticed recently that I
| | > | > | | > | > wasn't
| | > | > | | > | > receiving
| | > | > | | > | > mail that I expected to be getting (like metacello
| | > | > | | > | > membership
| | > | > | | > | > pending) ... I've cc'd the metacello list so we can
| | > | > | | > | > continue
| | > | > | | > | > the
| | > | > | | > | > conversation there..
| | > | > | | > | >
| | > | > | | > | > Two things:
| | > | > | | > | >
| | > | > | | > | >  1. the fetching old versions of packages does
| | > | > | | > | >  happen
| | > | > | | > | >  ...
| | > | > | | > | >  they
| | > | > | | > | >  are
| | > | > | | > | >  not _loaded_ but they
| | > | > | | > | >     do get fetched ... this would be a tough nut to
| | > | > | | > | >     crack
| | > | > | | > | >     with
| | > | > | | > | >     the
| | > | > | | > | >     current version
| | > | > | | > | >     of Metacello
| | > | > | | > | >  2. I'm about to release (today or tomorrow) a
| | > | > | | > | >  pre-release
| | > | > | | > | >  version
| | > | > | | > | >  of Metacello that
| | > | > | | > | >     introduces a scripting API that is intended to
| | > | > | | > | >     allow
| | > | > | | > | >     you
| | > | > | | > | >     to
| | > | > | | > | >     "pin" projects to a
| | > | > | | > | >     particular version (without editting configs)
| | > | > | | > | >     and
| | > | > | | > | >     no
| | > | > | | > | >     fetching
| | > | > | | > | >     of packages from
| | > | > | | > | >     older versions will occur .... so you'd be the
| | > | > | | > | >     "perfect
| | > | > | | > | >     test
| | > | > | | > | >     case".
| | > | > | | > | >
| | > | > | | > | > This pre-release version of Metacello should not
| | > | > | | > | > have
| | > | > | | > | > any
| | > | > | | > | > behavior
| | > | > | | > | > differences from the current released version of
| | > | > | | > | > Metacello
| | > | > | | > | > with
| | > | > | | > | > the exception of the addition of git/github support
| | > | > | | > | > (which
| | > | > | | > | > you
| | > | > | | > | > don't need) and the scripting api (which you do).
| | > | > | | > | >
| | > | > | | > | > So if you are willing I'd like you to attempt to
| | > | > | | > | > use
| | > | > | | > | > the
| | > | > | | > | > pre-release version of Metacello to get your job
| | > | > | | > | > done
| | > | > | | > | > ...
| | > | > | | > | > I'm
| | > | > | | > | > more
| | > | > | | > | > than willing to commit to fixing bugs and tweak
| | > | > | | > | > features
| | > | > | | > | > so
| | > | > | | > | > that
| | > | > | | > | > you can get Metacello to work for you ...
| | > | > | | > | >
| | > | > | | > | > I am suggesting that you use the pre-release
| | > | > | | > | > because
| | > | > | | > | > the
| | > | > | | > | > intent
| | > | > | | > | > of
| | > | > | | > | > the features that I've added to the scripting api
| | > | > | | > | > is
| | > | > | | > | > to:
| | > | > | | > | >
| | > | > | | > | >  be able to tell metacello to explicitly load a
| | > | > | | > | >  certain version of a project _regardless_ of what
| | > | > | | > | >  a
| | > | > | | > | >  dependent
| | > | > | | > | >  project's configuration has to say about that.
| | > | > | | > | >
| | > | > | | > | > There are actually two features of the API that
| | > | > | | > | > come
| | > | > | | > | > into
| | > | > | | > | > play:
| | > | > | | > | >
| | > | > | | > | >  1. the project registry
| | > | > | | > | >  2. the ability to customize upgrades/downgrades
| | > | > | | > | >
| | > | > | | > | > The project registry records the projectSpecs that
| | > | > | | > | > you
| | > | > | | > | > used
| | > | > | | > | > when
| | > | > | | > | > loading the image ... so the api knows exactly what
| | > | > | | > | > you
| | > | > | | > | > loaded.
| | > | > | | > | > You can add a specification to the registry BEFORE
| | > | > | | > | > the
| | > | > | | > | > project
| | > | > | | > | > is
| | > | > | | > | > actually loaded so that when a project has that
| | > | > | | > | > project
| | > | > | | > | > as a
| | > | > | | > | > dependency the version in the registry will be
| | > | > | | > | > used.
| | > | > | | > | > You
| | > | > | | > | > can
| | > | > | | > | > lock
| | > | > | | > | > project registrations so that an error will be
| | > | > | | > | > thrown
| | > | > | | > | > if
| | > | > | | > | > an
| | > | > | | > | > attempt is made to load a different version of the
| | > | > | | > | > specified
| | > | > | | > | > project.
| | > | > | | > | >
| | > | > | | > | > The customization comes into play when you hit a
| | > | > | | > | > load
| | > | > | | > | > expression
| | > | > | | > | > that causes a lock error or that you know will do
| | > | > | | > | > something
| | > | > | | > | > you
| | > | > | | > | > don't want...for every project upgrade/downgrade
| | > | > | | > | > during a
| | > | > | | > | > load,
| | > | > | | > | > you have the opportunity `allow` or `disallow` the
| | > | > | | > | > action. By
| | > | > | | > | > default upgrades are allowed and downgrades are
| | > | > | | > | > disallowed,
| | > | > | | > | > but
| | > | > | | > | > you can specify your own rules ...
| | > | > | | > | >
| | > | > | | > | > In your case you will want to `lock` Seaside to a
| | > | > | | > | > particular
| | > | > | | > | > version and repository:
| | > | > | | > | >
| | > | > | | > | >  Metacello new
| | > | > | | > | >    configuration: 'Seaside30';
| | > | > | | > | >    version: '3.0.7.1';
| | > | > | | > | >    repository: '<repository description for your
| | > | > | | > | >    override
| | > | > | | > | >    repository>';
| | > | > | | > | >    lock.
| | > | > | | > | >
| | > | > | | > | > Then when you load Seaside-Testing you use the api
| | > | > | | > | > to
| | > | > | | > | > deny
| | > | > | | > | > upgrades/downgrades for Seaside30 and bypass lock
| | > | > | | > | > violation
| | > | > | | > | > errors:
| | > | > | | > | >
| | > | > | | > | >  Metacello new
| | > | > | | > | >    configuration: 'Seaside-Testing';
| | > | > | | > | >    version: #stable;
| | > | > | | > | >    repository: '<repositiory description for
| | > | > | | > | >    Seaside-Testing
| | > | > | | > | >    config>';
| | > | > | | > | >    onUpgrade: [:ex :existing :new |
| | > | > | | > | >      new baseName = 'Seaside30
| | > | > | | > | >        ifTrue: [ ex disallow ].
| | > | > | | > | >      ex pass];
| | > | > | | > | >    onDowngrade: [:ex :existing :new |
| | > | > | | > | >      new baseName = 'Seaside30
| | > | > | | > | >        ifTrue: [ ex disallow ].
| | > | > | | > | >      ex pass]
| | > | > | | > | >    load.
| | > | > | | > | >
| | > | > | | > | > Technically you can probably get by without the
| | > | > | | > | > onUpgrade:
| | > | > | | > | > onDowngrade: blocks in this case, because the
| | > | > | | > | > pre-registration
| | > | > | | > | > of
| | > | > | | > | > Seaside30 should cause Seaside-Testing to use
| | > | > | | > | > 3.0.7.1
| | > | > | | > | > instead
| | > | > | | > | > of
| | > | > | | > | > 3.0.0-rc.2...
| | > | > | | > | >
| | > | > | | > | > So if you are willing to be a guinea pig, give me
| | > | > | | > | > the
| | > | > | | > | > particulars
| | > | > | | > | > of the version of pharo that you are using
| | > | > | | > | > (pharo-1.3
| | > | > | | > | > and
| | > | > | | > | > pharo-1.4 are known to work ... pharo-2.0 has
| | > | > | | > | > issues
| | > | > | | > | > and
| | > | > | | > | > I
| | > | > | | > | > just
| | > | > | | > | > haven't tried pharo-1.2 and earlier versions yet
| | > | > | | > | > ...
| | > | > | | > | > it
| | > | > | | > | > also
| | > | > | | > | > known
| | > | > | | > | > to work on Squeak4.3, GemStone2.4 and GemStone3.1)
| | > | > | | > | > and if
| | > | > | | > | > you're
| | > | > | | > | > using something other that 1.3 or 1.4 I'll ensure
| | > | > | | > | > that
| | > | > | | > | > the
| | > | > | | > | > api
| | > | > | | > | > works there.
| | > | > | | > | >
| | > | > | | > | > So what do you think?
| | > | > | | > | >
| | > | > | | > | > Dale
| | > | > | | > | >
| | > | > | | > | > [1]
| | > | > | | > | > http://code.google.com/p/metacello/issues/detail?id=150
| | > | > | | > | > ----- Original Message -----
| | > | > | | > | > | From: "Johan Brichau" <[hidden email]>
| | > | > | | > | > | To: "Dale Henrichs" <[hidden email]>
| | > | > | | > | > | Sent: Thursday, July 26, 2012 8:18:22 AM
| | > | > | | > | > | Subject: metacello diamond project dependency
| | > | > | | > | > | problem
| | > | > | | > | > |
| | > | > | | > | > | Hi Dale,
| | > | > | | > | > |
| | > | > | | > | > | I wanted to send this to the metacello group, but
| | > | > | | > | > | I
| | > | > | | > | > | do
| | > | > | | > | > | not
| | > | > | | > | > | have
| | > | > | | > | > | access (yet).
| | > | > | | > | > | Since I'm stuck with it, I thought to ask you
| | > | > | | > | > | directly
| | > | > | | > | > | already.
| | > | > | | > | > |
| | > | > | | > | > | I have a problem with diamond project
| | > | > | | > | > | dependencies
| | > | > | | > | > | in
| | > | > | | > | > | metacello:
| | > | > | | > | > |
| | > | > | | > | > | YesPlan explicitly requires Seaside 3.0.7.1
| | > | > | | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| | > | > | | > | > | Seaside-Testing explicitly requires Seaside
| | > | > | | > | > | 3.0.0-rc.2
| | > | > | | > | > |
| | > | > | | > | > | All project dependencies use the (default)
| | > | > | | > | > | version
| | > | > | | > | > | operator
| | > | > | | > | > | (#>=)
| | > | > | | > | > |
| | > | > | | > | > | Launching the load eventually triggers fetch
| | > | > | | > | > | operations
| | > | > | | > | > | for
| | > | > | | > | > | packages
| | > | > | | > | > | of Seaside 3.0.0-rc.2.
| | > | > | | > | > | However, I do not want this version of Seaside to
| | > | > | | > | > | load.
| | > | > | | > | > | I
| | > | > | | > | > | want
| | > | > | | > | > | the
| | > | > | | > | > | version specified in my Yesplan config.
| | > | > | | > | > |
| | > | > | | > | > | I have similar problems in the inverse direction:
| | > | > | | > | > | i.e.
| | > | > | | > | > | when
| | > | > | | > | > | I
| | > | > | | > | > | update
| | > | > | | > | > | the Seaside-Testing configuration to require the
| | > | > | | > | > | #stable
| | > | > | | > | > | Seaside
| | > | > | | > | > | version, it tries to fetch packages for a more
| | > | > | | > | > | recent
| | > | > | | > | > | Seaside
| | > | > | | > | > | version than I want to (i.e. for an older version
| | > | > | | > | > | of
| | > | > | | > | > | Yesplan):
| | > | > | | > | > |
| | > | > | | > | > | YesPlan explicitly requires Seaside 3.0.6.4
| | > | > | | > | > | Yesplan explicitly requires Seaside-Testing 0.7
| | > | > | | > | > | Seaside-Testing explicitly requires Seaside
| | > | > | | > | > | #stable
| | > | > | | > | > |
| | > | > | | > | > | It seems I want to be able to tell metacello to
| | > | > | | > | > | explicitly
| | > | > | | > | > | load a
| | > | > | | > | > | certain version of a project _regardless_ of what
| | > | > | | > | > | a
| | > | > | | > | > | dependent
| | > | > | | > | > | project's configuration has to say about that.
| | > | > | | > | > |
| | > | > | | > | > | The issue is that I want to protect my load from
| | > | > | | > | > | using
| | > | > | | > | > | any
| | > | > | | > | > | packages
| | > | > | | > | > | that I did not replicate to my local repository
| | > | > | | > | > | (I'm
| | > | > | | > | > | using
| | > | > | | > | > | a
| | > | > | | > | > | #repositoryOverrides: during the load). Now, with
| | > | > | | > | > | the
| | > | > | | > | > | first
| | > | > | | > | > | situation above, I would have expected that the
| | > | > | | > | > | dependency
| | > | > | | > | > | of
| | > | > | | > | > | SeasideTesting on an older version of Seaside
| | > | > | | > | > | would
| | > | > | | > | > | have
| | > | > | | > | > | been
| | > | > | | > | > | ignored. However, it's trying to fetch old
| | > | > | | > | > | packages
| | > | > | | > | > | which I
| | > | > | | > | > | do
| | > | > | | > | > | not
| | > | > | | > | > | have on my local repository. For the second
| | > | > | | > | > | situation,
| | > | > | | > | > | I
| | > | > | | > | > | did
| | > | > | | > | > | expect
| | > | > | | > | > | the problem but nevertheless I would like to
| | > | > | | > | > | avoid
| | > | > | | > | > | it.
| | > | > | | > | > |
| | > | > | | > | > | In general, this is a problem I experience
| | > | > | | > | > | frequently:
| | > | > | | > | > | some
| | > | > | | > | > | project's
| | > | > | | > | > | #stable version moved up a version but I do not
| | > | > | | > | > | want to
| | > | > | | > | > | follow
| | > | > | | > | > | that
| | > | > | | > | > | upgrade. Is it possible to do that without
| | > | > | | > | > | manually
| | > | > | | > | > | fixing
| | > | > | | > | > | the
| | > | > | | > | > | configuration file in each of the configurations
| | > | > | | > | > | I
| | > | > | | > | > | include?
| | > | > | | > | > |
| | > | > | | > | > | I hope you can make sense of my question ;-)
| | > | > | | > | > |
| | > | > | | > | > | Johan
| | > | > | | > |
| | > | > | |
| | > | > | |
| | > | > |
| | > |
| | > |
| |
| |