strange bevahiour between three dependent Metacello configurations
Hi, We are having the following problem when trying to update GTolols to their latest version in the latest Pharo 4 image: Rubric does not get updated. We have: -- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline) Performing [1] shows that rubric gets updated (atomic load : 0.2-baseline [ConfigurationOfRubric]) Performing [2] contains no trace of rubric. [1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective. Loading then the inspector [3] does not update Rubric. Loading just Glamour [4] updates it. [3] (ConfigurationOfGTInspectorCore project version: #development) load. [4] (ConfigurationOfGlamourCore project version: #development) load Any ideas or sugestions? Maybe we are missing something trivial. This updates the previous configurations to their latest versions: Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspectorCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; package: 'ConfigurationOfRubric'; load. Cheers, Andrei
Hi, We fixed this but we are not sure if the behaviour that we got was a result of a bug or a feature in Metacello. Again our setup is that we have three configurations with linear dependencies between them: -- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline) In ConfigurationOfRubric we had version "1.2.8" that uses '0.2-baseline'. The development version is '0.2-baseline' and the stable version '1.2.8' [1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective. When performing [1] Metacello decides to load Rubric. This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" (since none was specified before) to figure out whether something should be loaded. At a certain point this is executed: compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec = #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE ===> Rubric is not removed from the loader list When performing [2] Metacello decides not to load Rubric. In this case Metacello deals first with #ConfigurationOfGlamourCore. But after "GlamorCore" has been processed, the operator in the global mcLoader is set to ">=". All further specs-to-load (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now rubric get's removed: compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec >= #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE ===> Rubric is removed from the loader list That's why "Rubric" doesn't show up in the final loader list. The second (inner/nested) spec-to-load will remove it (after it has been successfully resolved by the previous nested configuration ConfigurationOfGlamourCore) because of the operator. So there is a difference between #ConfigurationOfGlamourCore and #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded. Anybody else encountered this? Cheers, GT team On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:
Hi,
We are having the following problem when trying to update GTolols to their latest version in the latest Pharo 4 image: Rubric does not get updated. We have:
-- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
Performing [1] shows that rubric gets updated (atomic load : 0.2-baseline [ConfigurationOfRubric]) Performing [2] contains no trace of rubric.
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
Loading then the inspector [3] does not update Rubric. Loading just Glamour [4] updates it.
[3] (ConfigurationOfGTInspectorCore project version: #development) load. [4] (ConfigurationOfGlamourCore project version: #development) load
Any ideas or sugestions? Maybe we are missing something trivial. This updates the previous configurations to their latest versions:
Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspectorCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; package: 'ConfigurationOfRubric'; load.
Cheers, Andrei
Hi, We solved it but we could still need some help from you. Without using gofer to load/update metacello configurations manually/explicitly, is there a way to force metacello to update existing configurations to the very latest ones while metacello is loading a configuration ? Example: The dependencies of the configurations is as follows: ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter ... Whereas ConfigurationOfGTInspectorCore, ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are already in a fresh Pharo 4 image (but outdated) Updating and loading "ConfigurationOfGToolkitCore" will only load itself and the latest packages that are defined by the configurations which are already in the image. But we would actually like to update those configurations (and their packages) as well. Otherwise the load would be "incomplete" (dependencies broken). Can Metacello do that ? Is there an easy way to do it ? Or is gofer the only solution ? How do you handle configurations that depend on other configurations (already loaded, but outdated) ? <-> Consistency of dependencies Thanks stef ---------- What we want is equivalent to the following snippet: { 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ :aConfigurationName | Gofer new smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; package: aConfigurationName; load ]. (ConfigurationOfGToolkitCore project version: #development) load. Am 04/03/15 um 14:53 schrieb Andrei Chis:
Hi,
We fixed this but we are not sure if the behaviour that we got was a result of a bug or a feature in Metacello.
Again our setup is that we have three configurations with linear dependencies between them: -- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
In ConfigurationOfRubric we had version "1.2.8" that uses '0.2-baseline'.
The development version is '0.2-baseline' and the stable version '1.2.8'
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
When performing [1] Metacello decides to load Rubric. This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" (since none was specified before) to figure out whether something should be loaded. At a certain point this is executed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec = #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE ===> Rubric is not removed from the loader list
When performing [2] Metacello decides not to load Rubric. In this case Metacello deals first with #ConfigurationOfGlamourCore. But after "GlamorCore" has been processed, the operator in the global mcLoader is set to ">=". All further specs-to-load (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now rubric get's removed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec >= #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE ===> Rubric is removed from the loader list
That's why "Rubric" doesn't show up in the final loader list. The second (inner/nested) spec-to-load will remove it (after it has been successfully resolved by the previous nested configuration ConfigurationOfGlamourCore) because of the operator.
So there is a difference between #ConfigurationOfGlamourCore and #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded.
Anybody else encountered this?
Cheers, GT team
On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:
Hi,
We are having the following problem when trying to update GTolols to their latest version in the latest Pharo 4 image: Rubric does not get updated. We have:
-- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
Performing [1] shows that rubric gets updated (atomic load : 0.2-baseline [ConfigurationOfRubric]) Performing [2] contains no trace of rubric.
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
Loading then the inspector [3] does not update Rubric. Loading just Glamour [4] updates it.
[3] (ConfigurationOfGTInspectorCore project version: #development) load. [4] (ConfigurationOfGlamourCore project version: #development) load
Any ideas or sugestions? Maybe we are missing something trivial. This updates the previous configurations to their latest versions:
Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspectorCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; package: 'ConfigurationOfRubric'; load.
Cheers, Andrei
Stef, You can use the `get` command in the Metacello scripting api[1] to force a reload of a ConfigurationOf/BaselineOf. I don't think that the lastest version of Metacello is loaded into Pharo4.0/Pharo3.0 so you probably should explicitly load Metacello[2] (that'll work for Pharo4.0 and Pharo3.0) .... If you are going to use the Metacello scripting api, then you should be using the scripting api for loading as well ... the scripting API records the versions of projects that you've loaded into the image while the old way of loading calculates the loaded version which is slow and at times just plain wrong. Metacello new configuration: 'GlamourCore'; version: #development; get; load Refreshes the ConfigurationOfGlamourCore and then does the load. There is also a bit more documentation in the Metacello User Guide[3]... Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScri... [2] https://github.com/dalehenrich/metacello-work#pharo30 [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser... On 03/04/2015 08:57 AM, Stefan Reichhart wrote:
Hi,
We solved it but we could still need some help from you.
Without using gofer to load/update metacello configurations manually/explicitly, is there a way to force metacello to update existing configurations to the very latest ones while metacello is loading a configuration ?
Example:
The dependencies of the configurations is as follows: ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter ... Whereas ConfigurationOfGTInspectorCore, ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are already in a fresh Pharo 4 image (but outdated)
Updating and loading "ConfigurationOfGToolkitCore" will only load itself and the latest packages that are defined by the configurations which are already in the image. But we would actually like to update those configurations (and their packages) as well. Otherwise the load would be "incomplete" (dependencies broken).
Can Metacello do that ? Is there an easy way to do it ? Or is gofer the only solution ?
How do you handle configurations that depend on other configurations (already loaded, but outdated) ? <-> Consistency of dependencies
Thanks stef
----------
What we want is equivalent to the following snippet:
{ 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ :aConfigurationName | Gofer new smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; package: aConfigurationName; load ]. (ConfigurationOfGToolkitCore project version: #development) load.
Am 04/03/15 um 14:53 schrieb Andrei Chis:
Hi,
We fixed this but we are not sure if the behaviour that we got was a result of a bug or a feature in Metacello.
Again our setup is that we have three configurations with linear dependencies between them: -- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
In ConfigurationOfRubric we had version "1.2.8" that uses '0.2-baseline'.
The development version is '0.2-baseline' and the stable version '1.2.8'
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
When performing [1] Metacello decides to load Rubric. This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" (since none was specified before) to figure out whether something should be loaded. At a certain point this is executed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec = #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE ===> Rubric is not removed from the loader list
When performing [2] Metacello decides not to load Rubric. In this case Metacello deals first with #ConfigurationOfGlamourCore. But after "GlamorCore" has been processed, the operator in the global mcLoader is set to ">=". All further specs-to-load (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now rubric get's removed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec >= #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE ===> Rubric is removed from the loader list
That's why "Rubric" doesn't show up in the final loader list. The second (inner/nested) spec-to-load will remove it (after it has been successfully resolved by the previous nested configuration ConfigurationOfGlamourCore) because of the operator.
So there is a difference between #ConfigurationOfGlamourCore and #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded.
Anybody else encountered this?
Cheers, GT team
On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:
Hi,
We are having the following problem when trying to update GTolols to their latest version in the latest Pharo 4 image: Rubric does not get updated. We have:
-- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
Performing [1] shows that rubric gets updated (atomic load : 0.2-baseline [ConfigurationOfRubric]) Performing [2] contains no trace of rubric.
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
Loading then the inspector [3] does not update Rubric. Loading just Glamour [4] updates it.
[3] (ConfigurationOfGTInspectorCore project version: #development) load. [4] (ConfigurationOfGlamourCore project version: #development) load
Any ideas or sugestions? Maybe we are missing something trivial. This updates the previous configurations to their latest versions:
Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspectorCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; package: 'ConfigurationOfRubric'; load.
Cheers, Andrei
thanks cheers stef Am 04/03/15 um 18:58 schrieb Dale Henrichs:
Stef,
You can use the `get` command in the Metacello scripting api[1] to force a reload of a ConfigurationOf/BaselineOf.
I don't think that the lastest version of Metacello is loaded into Pharo4.0/Pharo3.0 so you probably should explicitly load Metacello[2] (that'll work for Pharo4.0 and Pharo3.0) ....
If you are going to use the Metacello scripting api, then you should be using the scripting api for loading as well ... the scripting API records the versions of projects that you've loaded into the image while the old way of loading calculates the loaded version which is slow and at times just plain wrong.
Metacello new configuration: 'GlamourCore'; version: #development; get; load
Refreshes the ConfigurationOfGlamourCore and then does the load.
There is also a bit more documentation in the Metacello User Guide[3]...
Dale
[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScri...
[2] https://github.com/dalehenrich/metacello-work#pharo30 [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
On 03/04/2015 08:57 AM, Stefan Reichhart wrote:
Hi,
We solved it but we could still need some help from you.
Without using gofer to load/update metacello configurations manually/explicitly, is there a way to force metacello to update existing configurations to the very latest ones while metacello is loading a configuration ?
Example:
The dependencies of the configurations is as follows: ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter ... Whereas ConfigurationOfGTInspectorCore, ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are already in a fresh Pharo 4 image (but outdated)
Updating and loading "ConfigurationOfGToolkitCore" will only load itself and the latest packages that are defined by the configurations which are already in the image. But we would actually like to update those configurations (and their packages) as well. Otherwise the load would be "incomplete" (dependencies broken).
Can Metacello do that ? Is there an easy way to do it ? Or is gofer the only solution ?
How do you handle configurations that depend on other configurations (already loaded, but outdated) ? <-> Consistency of dependencies
Thanks stef
----------
What we want is equivalent to the following snippet:
{ 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ :aConfigurationName | Gofer new smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; package: aConfigurationName; load ]. (ConfigurationOfGToolkitCore project version: #development) load.
Am 04/03/15 um 14:53 schrieb Andrei Chis:
Hi,
We fixed this but we are not sure if the behaviour that we got was a result of a bug or a feature in Metacello.
Again our setup is that we have three configurations with linear dependencies between them: -- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
In ConfigurationOfRubric we had version "1.2.8" that uses '0.2-baseline'.
The development version is '0.2-baseline' and the stable version '1.2.8'
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
When performing [1] Metacello decides to load Rubric. This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" (since none was specified before) to figure out whether something should be loaded. At a certain point this is executed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec = #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE ===> Rubric is not removed from the loader list
When performing [2] Metacello decides not to load Rubric. In this case Metacello deals first with #ConfigurationOfGlamourCore. But after "GlamorCore" has been processed, the operator in the global mcLoader is set to ">=". All further specs-to-load (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now rubric get's removed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec >= #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE ===> Rubric is removed from the loader list
That's why "Rubric" doesn't show up in the final loader list. The second (inner/nested) spec-to-load will remove it (after it has been successfully resolved by the previous nested configuration ConfigurationOfGlamourCore) because of the operator.
So there is a difference between #ConfigurationOfGlamourCore and #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded.
Anybody else encountered this?
Cheers, GT team
On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:
Hi,
We are having the following problem when trying to update GTolols to their latest version in the latest Pharo 4 image: Rubric does not get updated. We have:
-- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
Performing [1] shows that rubric gets updated (atomic load : 0.2-baseline [ConfigurationOfRubric]) Performing [2] contains no trace of rubric.
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
Loading then the inspector [3] does not update Rubric. Loading just Glamour [4] updates it.
[3] (ConfigurationOfGTInspectorCore project version: #development) load. [4] (ConfigurationOfGlamourCore project version: #development) load
Any ideas or sugestions? Maybe we are missing something trivial. This updates the previous configurations to their latest versions:
Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspectorCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; package: 'ConfigurationOfRubric'; load.
Cheers, Andrei
Dale should we load the latest version of Metacello for Pharo 40? Stef Le 4/3/15 18:58, Dale Henrichs a écrit :
Stef,
You can use the `get` command in the Metacello scripting api[1] to force a reload of a ConfigurationOf/BaselineOf.
I don't think that the lastest version of Metacello is loaded into Pharo4.0/Pharo3.0 so you probably should explicitly load Metacello[2] (that'll work for Pharo4.0 and Pharo3.0) ....
If you are going to use the Metacello scripting api, then you should be using the scripting api for loading as well ... the scripting API records the versions of projects that you've loaded into the image while the old way of loading calculates the loaded version which is slow and at times just plain wrong.
Metacello new configuration: 'GlamourCore'; version: #development; get; load
Refreshes the ConfigurationOfGlamourCore and then does the load.
There is also a bit more documentation in the Metacello User Guide[3]...
Dale
[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScri... [2] https://github.com/dalehenrich/metacello-work#pharo30 [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
On 03/04/2015 08:57 AM, Stefan Reichhart wrote:
Hi,
We solved it but we could still need some help from you.
Without using gofer to load/update metacello configurations manually/explicitly, is there a way to force metacello to update existing configurations to the very latest ones while metacello is loading a configuration ?
Example:
The dependencies of the configurations is as follows: ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter ... Whereas ConfigurationOfGTInspectorCore, ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are already in a fresh Pharo 4 image (but outdated)
Updating and loading "ConfigurationOfGToolkitCore" will only load itself and the latest packages that are defined by the configurations which are already in the image. But we would actually like to update those configurations (and their packages) as well. Otherwise the load would be "incomplete" (dependencies broken).
Can Metacello do that ? Is there an easy way to do it ? Or is gofer the only solution ?
How do you handle configurations that depend on other configurations (already loaded, but outdated) ? <-> Consistency of dependencies
Thanks stef
----------
What we want is equivalent to the following snippet:
{ 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ :aConfigurationName | Gofer new smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; package: aConfigurationName; load ]. (ConfigurationOfGToolkitCore project version: #development) load.
Am 04/03/15 um 14:53 schrieb Andrei Chis:
Hi,
We fixed this but we are not sure if the behaviour that we got was a result of a bug or a feature in Metacello.
Again our setup is that we have three configurations with linear dependencies between them: -- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
In ConfigurationOfRubric we had version "1.2.8" that uses '0.2-baseline'.
The development version is '0.2-baseline' and the stable version '1.2.8'
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
When performing [1] Metacello decides to load Rubric. This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" (since none was specified before) to figure out whether something should be loaded. At a certain point this is executed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec = #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE ===> Rubric is not removed from the loader list
When performing [2] Metacello decides not to load Rubric. In this case Metacello deals first with #ConfigurationOfGlamourCore. But after "GlamorCore" has been processed, the operator in the global mcLoader is set to ">=". All further specs-to-load (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now rubric get's removed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec >= #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE ===> Rubric is removed from the loader list
That's why "Rubric" doesn't show up in the final loader list. The second (inner/nested) spec-to-load will remove it (after it has been successfully resolved by the previous nested configuration ConfigurationOfGlamourCore) because of the operator.
So there is a difference between #ConfigurationOfGlamourCore and #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded.
Anybody else encountered this?
Cheers, GT team
On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:
Hi,
We are having the following problem when trying to update GTolols to their latest version in the latest Pharo 4 image: Rubric does not get updated. We have:
-- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
Performing [1] shows that rubric gets updated (atomic load : 0.2-baseline [ConfigurationOfRubric]) Performing [2] contains no trace of rubric.
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
Loading then the inspector [3] does not update Rubric. Loading just Glamour [4] updates it.
[3] (ConfigurationOfGTInspectorCore project version: #development) load. [4] (ConfigurationOfGlamourCore project version: #development) load
Any ideas or sugestions? Maybe we are missing something trivial. This updates the previous configurations to their latest versions:
Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspectorCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; package: 'ConfigurationOfRubric'; load.
Cheers, Andrei
Stef, Yeah I think so ... I've been running tests against Pharo4.0 for a while now[1] and the rate of change is pretty low, so picking up the latest version of Metacello from the master branch would be a good thing... Dale [1] https://travis-ci.org/dalehenrich/metacello-work On 03/15/2015 02:09 PM, stepharo wrote:
Dale should we load the latest version of Metacello for Pharo 40?
Stef
Le 4/3/15 18:58, Dale Henrichs a écrit :
Stef,
You can use the `get` command in the Metacello scripting api[1] to force a reload of a ConfigurationOf/BaselineOf.
I don't think that the lastest version of Metacello is loaded into Pharo4.0/Pharo3.0 so you probably should explicitly load Metacello[2] (that'll work for Pharo4.0 and Pharo3.0) ....
If you are going to use the Metacello scripting api, then you should be using the scripting api for loading as well ... the scripting API records the versions of projects that you've loaded into the image while the old way of loading calculates the loaded version which is slow and at times just plain wrong.
Metacello new configuration: 'GlamourCore'; version: #development; get; load
Refreshes the ConfigurationOfGlamourCore and then does the load.
There is also a bit more documentation in the Metacello User Guide[3]...
Dale
[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScri... [2] https://github.com/dalehenrich/metacello-work#pharo30 [3] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUser...
On 03/04/2015 08:57 AM, Stefan Reichhart wrote:
Hi,
We solved it but we could still need some help from you.
Without using gofer to load/update metacello configurations manually/explicitly, is there a way to force metacello to update existing configurations to the very latest ones while metacello is loading a configuration ?
Example:
The dependencies of the configurations is as follows: ConfigurationOfGToolkitCore ---> ConfigurationOfGTInspectorCore + ConfigurationOfGTPlaygroundCore + ConfigurationOfGTSpotter ... Whereas ConfigurationOfGTInspectorCore, ConfigurationOfGTPlaygroundCore, ConfigurationOfGTSpotter are already in a fresh Pharo 4 image (but outdated)
Updating and loading "ConfigurationOfGToolkitCore" will only load itself and the latest packages that are defined by the configurations which are already in the image. But we would actually like to update those configurations (and their packages) as well. Otherwise the load would be "incomplete" (dependencies broken).
Can Metacello do that ? Is there an easy way to do it ? Or is gofer the only solution ?
How do you handle configurations that depend on other configurations (already loaded, but outdated) ? <-> Consistency of dependencies
Thanks stef
----------
What we want is equivalent to the following snippet:
{ 'ConfigurationOfGToolkitCore'. 'ConfigurationOfGTInspectorCore'. 'ConfigurationOfGTPlaygroundCore'. 'ConfigurationOfGTSpotter'. 'ConfigurationOfGlamourCore'. 'ConfigurationOfRubricCore' } do: [ :aConfigurationName | Gofer new smalltalkhubUser: 'Pharo' project: 'Pharo40Inbox'; package: aConfigurationName; load ]. (ConfigurationOfGToolkitCore project version: #development) load.
Am 04/03/15 um 14:53 schrieb Andrei Chis:
Hi,
We fixed this but we are not sure if the behaviour that we got was a result of a bug or a feature in Metacello.
Again our setup is that we have three configurations with linear dependencies between them: -- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
In ConfigurationOfRubric we had version "1.2.8" that uses '0.2-baseline'.
The development version is '0.2-baseline' and the stable version '1.2.8'
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
When performing [1] Metacello decides to load Rubric. This because "MetacelloNullRecordingMCSpecLoader" uses the operator "=" (since none was specified before) to figure out whether something should be loaded. At a certain point this is executed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec = #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" = "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> FALSE ===> Rubric is not removed from the loader list
When performing [2] Metacello decides not to load Rubric. In this case Metacello deals first with #ConfigurationOfGlamourCore. But after "GlamorCore" has been processed, the operator in the global mcLoader is set to ">=". All further specs-to-load (MetacelloNullRecordingMCSpecLoader) will be compared using "=>". So now rubric get's removed:
compareCurrentVersion:targetVersionStatus:using: (from above) ... ... ... ... #allLoadedToSpec >= #allLoadedToSpec ===> TRUE "1.2.8 [ConfigurationOfRubric]" >= "<>0.2-baseline [ConfigurationOfRubric] (MetacelloMCVersion)" ===> TRUE ===> Rubric is removed from the loader list
That's why "Rubric" doesn't show up in the final loader list. The second (inner/nested) spec-to-load will remove it (after it has been successfully resolved by the previous nested configuration ConfigurationOfGlamourCore) because of the operator.
So there is a difference between #ConfigurationOfGlamourCore and #ConfigurationOfGTInspectorCore in how "Rubric" is resolved and loaded.
Anybody else encountered this?
Cheers, GT team
On Tue, Mar 3, 2015 at 9:44 PM, Andrei Chis <chisvasileandrei@gmail.com <mailto:chisvasileandrei@gmail.com>> wrote:
Hi,
We are having the following problem when trying to update GTolols to their latest version in the latest Pharo 4 image: Rubric does not get updated. We have:
-- ConfigurationOfGTInspectorCore (2.0-baseline) -- ConfigurationOfGlamourCore (3.1-baseline) -- ConfigurationOfRubric (0.2-baseline)
Performing [1] shows that rubric gets updated (atomic load : 0.2-baseline [ConfigurationOfRubric]) Performing [2] contains no trace of rubric.
[1] (ConfigurationOfGlamourCore project version: #development) record loadDirective [2] (ConfigurationOfGTInspectorCore project version: #development) record loadDirective.
Loading then the inspector [3] does not update Rubric. Loading just Glamour [4] updates it.
[3] (ConfigurationOfGTInspectorCore project version: #development) load. [4] (ConfigurationOfGlamourCore project version: #development) load
Any ideas or sugestions? Maybe we are missing something trivial. This updates the previous configurations to their latest versions:
Gofer new smalltalkhubUser: 'Moose' project: 'GToolkit'; package: 'ConfigurationOfGTInspectorCore'; load. Gofer new smalltalkhubUser: 'Moose' project: 'Glamour'; package: 'ConfigurationOfGlamourCore'; load. Gofer new smalltalkhubUser: 'AlainPlantec' project: 'Rubric'; package: 'ConfigurationOfRubric'; load.
Cheers, Andrei
participants (4)
-
Andrei Chis -
Dale Henrichs -
Stefan Reichhart -
stepharo