Some Metacello issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Some Metacello issue

Holger Freyther
Hi,

after having made some new releases I have an odd Metacello issue and I am not sure how to debug it. This happens on my legacy Pharo3/Pharo4 images that I still need to support in deployment.

It seems to be related to a dependency chain of "app"->VoyageMongo->Magritte3 3.5.0 and somehow version '3.1.1.1' of Magritte3 doing something with Grease #stable and not finding a 'Core' group. Any idea how to debug it or if any configuration changed recently? It also only seems to happen if there are two dependency chains that try to load the same VoyageMongo version.


Broken:

pharo Pharo3.image config http://smalltalkhub.com/mc/osmocom/Osmocom/main ConfigurationOfOsmoUniverse --install=bleedingEdge

Error: Name not found: Core
MetacelloMCVersionSpec(Object)>>error:
MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpec:forLoad:forMap:packages: in Block: [ ^ self error: 'Name not found: ' , aString ]
MetacelloMCVersionSpec(MetacelloVersionSpec)>>packageNamed:forLoad:forMap:ifAbsent: in Block: [ ...
Dictionary>>at:ifAbsent:
MetacelloMCVersionSpec(MetacelloVersionSpec)>>packageNamed:forLoad:forMap:ifAbsent:
MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpec:forLoad:forMap:packages:
MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs:forLoad:map: in Block: [ :req | ...
Array(SequenceableCollection)>>do:
MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs:forLoad:map:
MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs:
MetacelloMCVersionSpec(MetacelloVersionSpec)>>expandToLoadableSpecNames: in Block: [ :cache | ...
MetacelloPharo30Platform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: in Block: [ :dict | ...
MetacelloPharo30Platform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: in Block: [ ^ aBlock value: dict ]
BlockClosure>>on:do:
...


Working:

Metacello new
        configuration: 'Magritte3';
        repository: 'http://www.smalltalkhub.com/mc/Magritte/Magritte3/main';
        version: '3.5.0';
        load



Reply | Threaded
Open this post in threaded view
|

Re: Some Metacello issue

Stephan Eggermont-3
On 07/06/17 06:19, Holger Freyther wrote:

> Hi,
>
> after having made some new releases I have an odd Metacello issue and
> I am not sure how to debug it. This happens on my legacy
> Pharo3/Pharo4 images that I still need to support in deployment.
>
> It seems to be related to a dependency chain of
> "app"->VoyageMongo->Magritte3 3.5.0 and somehow version '3.1.1.1' of
> Magritte3 doing something with Grease #stable and not finding a
> 'Core' group. Any idea how to debug it or if any configuration
> changed recently? It also only seems to happen if there are two
> dependency chains that try to load the same VoyageMongo version.

> Metacello new configuration: 'Magritte3'; repository:
> 'http://www.smalltalkhub.com/mc/Magritte/Magritte3/main'; version:
> '3.5.0'; load

version: #'release35' (or #'release3'

Never refer to fixed versions unless you know why (you need to avoid a
specific bug fix).

What is most likely is that there is some overconstrained configuration.
Does your ConfigurationOfVoyageMongo or one of the configurations it
pulls in refer to different versions of grease or magritte? Another
issue can be that there are older configurations already loaded that
conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk
is broken, refering to a fixed and older version of Grease.
ConfigurationOfVoyageMongo should probably be using #'release3' of
Magritte, but that doesn't break it.

Stephan




Reply | Threaded
Open this post in threaded view
|

Re: Some Metacello issue

Stephan Eggermont-3
In reply to this post by Holger Freyther
I would like to repeat here again: don't refer to fixed version numbers
of packages out of your control in configurations. Refer to #'release'
versions that can be patched by the maintainers of your dependencies.
That is only appropriate when having to patch around a problem, and
couples your configuration hard to the development schedule of your
dependency, making it your responsibility to update your configuration
whenever that of your dependency is updated.

Stephan




Reply | Threaded
Open this post in threaded view
|

Re: Some Metacello issue

Holger Freyther
In reply to this post by Stephan Eggermont-3

> On 7. Jun 2017, at 14:09, Stephan Eggermont <[hidden email]> wrote:
>
> Never refer to fixed versions unless you know why (you need to avoid a
> specific bug fix).

When wanting to have repeatable builds (e.g. for bugfixes) and in the
absence of other means to lock/define versions externally, I think using
a fixed version is the way to go.


> What is most likely is that there is some overconstrained configuration.
> Does your ConfigurationOfVoyageMongo or one of the configurations it
> pulls in refer to different versions of grease or magritte? Another
> issue can be that there are older configurations already loaded that
> conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk
> is broken, refering to a fixed and older version of Grease.
> ConfigurationOfVoyageMongo should probably be using #'release3' of
> Magritte, but that doesn't break it.

Right. So we have a "OsmocomUniverse" build job that pulls in all the
apps into a single image. This helps to make API modifications and not
forget any of the client code.

The configuration has such dependencies:

ConfigurationOfOsmocomUniverse
        -> ConfigurationOfHLR
                -> ConfigurationOfVoyageMongo
                        -> Mongotalk
                                -> Grease A
                        -> Magritte3
                                -> Grease B
        -> ConfigurationOfSMPPRouter
                -> ConfigurationOfVoyageMongo
                        -> Mongotalk
                                -> Grease A
                        -> Magritte3
                                -> Grease B

What happens is that somehow "Grease A" gets loaded, then "Grease B" and
when it is time for "Grease A" again.. the system kind of explodes and this
is for Pharo3 and Pharo6. Now the question to me is.. why is this coming
up right now? Did MongoTalk change or Magritte3 or something else?

Is there an easy way for Metacello to try a mirror instead of the original,
e.g. to inject an older ConfigurationOfMagritte3?


holger

Reply | Threaded
Open this post in threaded view
|

Re: Some Metacello issue

Dale Henrichs-3


On 06/07/2017 03:46 AM, Holger Freyther wrote:

>> On 7. Jun 2017, at 14:09, Stephan Eggermont <[hidden email]> wrote:
>>
>> Never refer to fixed versions unless you know why (you need to avoid a
>> specific bug fix).
> When wanting to have repeatable builds (e.g. for bugfixes) and in the
> absence of other means to lock/define versions externally, I think using
> a fixed version is the way to go.
>
>
>> What is most likely is that there is some overconstrained configuration.
>> Does your ConfigurationOfVoyageMongo or one of the configurations it
>> pulls in refer to different versions of grease or magritte? Another
>> issue can be that there are older configurations already loaded that
>> conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk
>> is broken, refering to a fixed and older version of Grease.
>> ConfigurationOfVoyageMongo should probably be using #'release3' of
>> Magritte, but that doesn't break it.
> Right. So we have a "OsmocomUniverse" build job that pulls in all the
> apps into a single image. This helps to make API modifications and not
> forget any of the client code.
>
> The configuration has such dependencies:
>
> ConfigurationOfOsmocomUniverse
> -> ConfigurationOfHLR
> -> ConfigurationOfVoyageMongo
> -> Mongotalk
> -> Grease A
> -> Magritte3
> -> Grease B
> -> ConfigurationOfSMPPRouter
> -> ConfigurationOfVoyageMongo
> -> Mongotalk
> -> Grease A
> -> Magritte3
> -> Grease B
>
> What happens is that somehow "Grease A" gets loaded, then "Grease B" and
> when it is time for "Grease A" again.. the system kind of explodes and this
> is for Pharo3 and Pharo6. Now the question to me is.. why is this coming
> up right now? Did MongoTalk change or Magritte3 or something else?
>
> Is there an easy way for Metacello to try a mirror instead of the original,
> e.g. to inject an older ConfigurationOfMagritte3?
>

I think that the `lock` command[1] is what you are looking for ...

Dale

[1]
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking

Reply | Threaded
Open this post in threaded view
|

Re: Some Metacello issue

DiegoLont
Hi all,

To keep the common projects in smalltalkhub stable, we agreed that those should use symbolic versions like release3 // release3.5 etc. This way we can add bug fixes and avoiding loading of different versions through different projects.

But I might have done something stupid to the configuration of magritte, especially release3:

When I added some features to Magritte, I saw that that the stable version in the configuration of Magritte3 was unstable for pharo2, 3 and 4 for quite some time. Basically the tests failed, because some changes were made for pharo 5 in order to let Magritte version 3.5 run. 

Since I did not have time to make a proper fix (and the error was there for quite a lot of builds) for the older pharo versions and I believe the tests for the stable version ought to be green, I thought the best way to fix it, was to changed the #release3 magritte version back to release 3.2 for the older pharo versions. Perhaps this is the cause of some of the problems. Tomorrow I have time to look into this problem and make a proper fix.

Stephane already notified me this is at least a problem for Pillar …

Regards,
Diego

On 07 Jun 2017, at 20:01, Dale Henrichs <[hidden email]> wrote:



On 06/07/2017 03:46 AM, Holger Freyther wrote:
On 7. Jun 2017, at 14:09, Stephan Eggermont <[hidden email]> wrote:

Never refer to fixed versions unless you know why (you need to avoid a
specific bug fix).
When wanting to have repeatable builds (e.g. for bugfixes) and in the
absence of other means to lock/define versions externally, I think using
a fixed version is the way to go.


What is most likely is that there is some overconstrained configuration.
Does your ConfigurationOfVoyageMongo or one of the configurations it
pulls in refer to different versions of grease or magritte? Another
issue can be that there are older configurations already loaded that
conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk
is broken, refering to a fixed and older version of Grease.
ConfigurationOfVoyageMongo should probably be using #'release3' of
Magritte, but that doesn't break it.
Right. So we have a "OsmocomUniverse" build job that pulls in all the
apps into a single image. This helps to make API modifications and not
forget any of the client code.

The configuration has such dependencies:

ConfigurationOfOsmocomUniverse
-> ConfigurationOfHLR
-> ConfigurationOfVoyageMongo
-> Mongotalk
-> Grease A
-> Magritte3
-> Grease B
-> ConfigurationOfSMPPRouter
-> ConfigurationOfVoyageMongo
-> Mongotalk
-> Grease A
-> Magritte3
-> Grease B

What happens is that somehow "Grease A" gets loaded, then "Grease B" and
when it is time for "Grease A" again.. the system kind of explodes and this
is for Pharo3 and Pharo6. Now the question to me is.. why is this coming
up right now? Did MongoTalk change or Magritte3 or something else?

Is there an easy way for Metacello to try a mirror instead of the original,
e.g. to inject an older ConfigurationOfMagritte3?


I think that the `lock` command[1] is what you are looking for ...

Dale

[1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking

Reply | Threaded
Open this post in threaded view
|

Re: Some Metacello issue

DiegoLont

> On 08 Jun 2017, at 09:36, Diego Lont <[hidden email]> wrote:
>
> Hi all,
>
> To keep the common projects in smalltalkhub stable, we agreed that those should use symbolic versions like release3 // release3.5 etc. This way we can add bug fixes and avoiding loading of different versions through different projects.
>
> But I might have done something stupid to the configuration of magritte, especially release3:
>
> When I added some features to Magritte, I saw that that the stable version in the configuration of Magritte3 was unstable for pharo2, 3 and 4 for quite some time. Basically the tests failed, because some changes were made for pharo 5 in order to let Magritte version 3.5 run.
>
> Since I did not have time to make a proper fix (and the error was there for quite a lot of builds) for the older pharo versions and I believe the tests for the stable version ought to be green, I thought the best way to fix it, was to changed the #release3 magritte version back to release 3.2 for the older pharo versions. Perhaps this is the cause of some of the problems. Tomorrow I have time to look into this problem and make a proper fix.
>
> Stephane already notified me this is at least a problem for Pillar …
>
Just a small addition: I just looked at Pillar, but the build of Pillar was building fine until beginning of this month. My change is from the beginning of May …