as people are increasingly starting to move to git and baselines, it is becoming more and more common that there are loading issues:
A depends on B and C
B depends on ConfigurationOfX
C depends on BaselineOfX
and then loading fails on
MetacelloConflictingProjectError: Load Conflict between existing
BaselineOfStateSpecs [baseline] from github://dionisiydk/StateSpecs:v2.4.x and ConfigurationOfStateSpecs stable from http://www.smalltalkhub.com/mc/dionisiy/StateSpecs/main
I imagine that this will become more and more common.
Can this be resolved in some automated fashion?
Metacello locks are supposed to address this kind of problem ... at this
point in time, any project that is loaded from a git project should be
'locked' using a Metacello lock.
The lock means that any request to load that project will use the locked
version instead of the version specified in the configuration/baseline.
A lock can be applied to a project without actually loading the project ...
Presuming that you have a preference towards using the local git
repository for project X, then you can lock project X with a reference
to the local git repository:
... and from this point on any attempt by Metacello to load project X
will load from the local git repository ...
Once you have a local clone of a project it is very likely that you will
want to share that repository amongst many of your local pharo projects
and to do that with Metacallo you need to lock those projects in each of
your images, including new images ...
This can lead to a lot of locking ... I talk about the approach that I
use in tODE to address this problem in two Smalltalks talks  and ...
On 11/9/17 12:21 PM, Peter Uhnák wrote:
> as people are increasingly starting to move to git and baselines, it
> is becoming more and more common that there are loading issues:
> A depends on B and C
> B depends on ConfigurationOfX
> C depends on BaselineOfX
> and then loading fails on
> MetacelloConflictingProjectError: Load Conflict between existing
> BaselineOfStateSpecs [baseline] from
> github://dionisiydk/StateSpecs:v2.4.x and ConfigurationOfStateSpecs
> stable from http://www.smalltalkhub.com/mc/dionisiy/StateSpecs/main
> I imagine that this will become more and more common.
> Can this be resolved in some automated fashion?
I am aware of locking, but that requires I know all the recursive dependencies so I can lock them before loading the project itself.
I can do that locally (and I've done it in the past), but I cannot easily force that upon users. This also applies for SmalltalkCI which will just try to load the baseline and will run into the conflict (the conflict pasted in the first mail actually comes from SCI).
On Thu, Nov 9, 2017 at 11:17 PM, Dale Henrichs <[hidden email]> wrote:
On 11/10/17 1:14 AM, Peter Uhnák wrote:
Ah .... well getting load conflicts is a feature in that case:)
In that case you are trying to load "two different" projects with the same name from incompatible repositories and someone has to decide ... the problem partially likes in the fact that the maintainers of project X haven't committed to a primary repository ...
The other part of the problem has to do with being able to specify conflict handling in SmalltalkCI ... the Metacello load command allows you to programmatically decide which side of the conflict wins during the load, but the SCIMetacelloLoadSpec hasn;t quite gotten to the point where the conflct resolution has been exposed
At the end of the day, the maintainers of project X need to make up their minds and SmalltalkCI needs to expose the conflict resolution api for Metacllo ...
|Free forum by Nabble - Resume Templates||Edit this page|