On 11/10/17 1:14 AM, Peter Uhnák wrote:

Hi Dale,

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). 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 ... Dale

Thanks, Peter

On Thu, Nov 9, 2017 at 11:17 PM, Dale Henrichs <dale.henrichs@gemtalksystems.com <mailto:dale.henrichs@gemtalksystems.com>> wrote:

Peter,

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:

  Metacello new

    project: 'X';

    repository: '......';

    lock.

... 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 [1] and [2]...

Dale

[1] https://www.youtube.com/watch?v=Ejmqs0xLvSk&list=PLCGAAdUizzH06AkHg6_UxZ6QZB... <https://www.youtube.com/watch?v=Ejmqs0xLvSk&list=PLCGAAdUizzH06AkHg6_UxZ6QZB...>

[2] https://www.youtube.com/watch?v=QshDlH1ADZQ <https://www.youtube.com/watch?v=QshDlH1ADZQ>

On 11/9/17 12:21 PM, Peter Uhnák wrote:

Hi,

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 <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?

Thanks, Peter