Help for odd conflict if dependency is listed twice

[zecke]

Dear Dale,

I am facing two separate issues and wonder if you could provide some hint on how to resolve or implement it.

1. When deploying an image I would like to externally lock down versions. E.g. something like a Gemfile in my application to say for "VoyageMongo" use "23.12" for "MongoTalk" use 12.12 and ideally get this file generated based on following the symbolic versions.

2. I load two of my apps into an image and both of them required "VoyageMongo". What seems to happen is that MongoTalk and Magritte3 load two different versions of Grease and as this happens twice something odd goes on and an exception is thrown. I lack a strategy to debug it properly. E.g. can I re-write URLs so that instead of smalltalkhub something else will be hit ("pre-mirror") or such?

The issue I have can be reproduced by the below. The failure differs a bit on Pharo3 vs. Pharo6.

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

[dalehenrich]

I think that the lock command is what you are looking for ......

The 'lock' command arranges for to use the specified version/repository for a project despite what version/repository is called as dependent projects for any projects being loaded into your system ... You have to use the Metacell new style of loading for all projects in order for the lock to take effect ...

[zecke]

Cool. Is there "infrastructure" to do something like "lock all" or have Metacello new... load generate a list of lock statements or from a running image generate a list of which versions are loaded right now?

[ThierryGoubier]

Yes. Query the metacello registry for loaded versions, and lock them.

MetacelloProjectRegistration registry registrations

Note that only projects loaded by Metacello are listed in the registry. Projects already present in the default pharo image or projects loaded by the catalog are not listed.

[zecke]

Cool! Thank you. I will try to automate this based on that. Do you think for BaselineOf we can find the sha1 sum of the commit as well?

[ThierryGoubier]

Probably not, because the baseline of may have been loaded in a non git supporting repository.

But...

There is an experimental branch in FileTree (GitFileTree) where package versions use git short commit ids (sha) instead of version numbers so just having the baseline package name would give you a handle on the full sha. This branch requires a lot of overriding on Monticello and Gofer because of their over-reliance on string-based version ordering and belief that a repository is too dumb to order versions by itself...

However, if you're using gitfiletree and your baseline was loaded by it, then the working copy of the BaselineOf has a MCGitFileTreeVersionInfo ancestor, and the id of this version info matches a single entry (and git commit id) in the repo of that MCGitFileTreeVersionInfo instance. There is no API to get that commit id, however but the following (with a repo accessor in the version info) will work:

(MCWorkingCopy registry
at: (MCPackage named: 'BaselineOfAltBrowser')) ancestry ancestors first
in: [ :wc | (wc repo allFileNames detect: [ :e | e info id = wc id ]) commitID ]

I haven't checked, but Iceberg may well track the same information.

[dalehenrich]

There is versionInfo slot in the MetacelloProjectRegistration where the SHA can be recorded at load time, so that the SHA used to load a package can be recorded as part of the registration ... VERY IMPORTANT.

There are hooks in Metacello to supply the SHA of the commit for a filetree repository. See:

• MCFileTreeRepository>>repositoryVersionString
• MetacelloPlatform>>gitCommitShaFor:

All that is needed is a Pharo-specific implementation of #gitCommitShaFor: in the Metacello. ONce that is done all newly created registrations will include the SHA ...