Stef,
If you need to leverage the multi-package load, you can do that in Metacello by
using the #atomic loadType in the project method of your configuration:
project
^ project
ifNil: [
"Bootstrap Metacello if it is not already loaded"
self class ensureMetacello.
project := self projectClass new projectAttributes: self
customProjectAttributes. "Create the Metacello project"
project versionNumberClass: self versionNumberClass.
project class versionConstructorClass on: self project: project.
"Construct the project"
project loadType: #'atomic'. "change to #atomic if desired"
project ]
With #atomic, all of the packages are loaded in one multi-package load. with
#linear (the default) each package is loaded individually.
If you inspect the loadDirectives that are produced by the #record message, the
load type is encoded in the class of the directive, so you can tell whether
#linear or #atomic loadTypes are used in the configurations...
Does this help?
Dale
----- Original Message -----
| From: "Stéphane Ducasse" <[email protected]>
| To: "Pharo Development" <[email protected]>
| Sent: Saturday, November 17, 2012 11:28:03 AM
| Subject: [Pharo-project] Metacello loading semantics
|
| Hi dale
|
| I implemented a little tool that
| - create a kind of specification (version, package, repo) for all
| the packages reachable from a configurationOf
| (see below method method
| packagesAndAssociatedRepositoriesFromConfigurationRecord )
|
| It generates a script looking as follows:
| script3
| ^ #(
| #('ConfigurationOfFame-TudorGirba.5.mcz'
| 'http://www.squeaksource.com/Fame/'
'ConfigurationOfFame' )
| #('ConfigurationOfMooseAlgos-usmanbhatti.27.mcz'
| 'http://www.squeaksource.com/MooseAlgos/'
| 'ConfigurationOfMooseAlgos' )
| #('ConfigurationOfGlamour-TudorGirba.98.mcz'
| 'http://www.squeaksource.com/Glamour/'
'ConfigurationOfGlamour'
| )
| #('ConfigurationOfDSM-AlexandreBergel.56.mcz'
| 'http://www.squeaksource.com/dsm/'
'ConfigurationOfDSM' )
| #('ConfigurationOfKumpel-AlexandreBergel.3.mcz'
| 'http://www.squeaksource.com/Kumpel/'
'ConfigurationOfKumpel' )
| #('ConfigurationOfSmallDud………….)
|
| - I keep the order given by Metacello. I extract the information as
| follows:
|
| packagesAndAssociatedRepositoriesFromConfigurationRecord:
| aConfigurationRecord
| "| record |
| record := ((Smalltalk globals at: #ConfigurationOfMoose) project
| version: 'default') ignoreImage: true; record.
| self packagesAndAssociatedRepositoriesFromConfigurationRecord:
| record
| "
|
| | pkgs |
| pkgs := OrderedCollection new.
| aConfigurationRecord loadDirective packageDirectivesDo:
| [:directive |
| pkgs add:
| {directive spec name, '*'.
| (self removeCache: directive spec workingCopy
| repositoryGroup repositories) anyOne
| locationWithTrailingSlash} ].
| ^ pkgs
|
|
| - then I try to load the package as follows:
|
| flatVersion47: spec
| <version: '4.7-flat'>
|
| spec for: #common do: [
| self populateSpec: spec with: self script3 ]
|
| I load them doing
| (ConfigurationOfMoose project version: '4.7-flat') load
| Now It does not work because after fetching all the packages, the
| system complain that some classes that will be loaded later are not
| present.
| I imagine that you use Gofer and that Gofer does not use the merging
| semantics of MC over multiple projects (that you can have multiple
| package in any order and that the classes get loaded - as I use it
| for the scriptLoader and below).
|
|
| - before I was doing it by doing a diff between the pharo package
| and the one loaded and I was loading the specification after
| installing the repository
| and the working copies using the MCVersionLoader and it worked I
| could reload completely Moose!
|
|
| load: aCollectionOfPackageString
| "self new
| load: #( 'Famix-C-TudorGirba.15'
| 'Famix-Core-NicolasAnquetil.201'))"
|
| | loader |
| loader := MCVersionLoader new.
| (self newerVersionsIn: aCollectionOfPackageString)
| do: [ :fn | loader addVersion: (self loadVersionFromFileNamed:
fn).
| (Delay forSeconds: 2) wait.]
| displayingProgress: 'Adding versions...'.
| loader hasVersions ifTrue: [loader load].
|
|
| So my question is
| - Does the packageDirectivesDo: provide an order that I can use to
| load package with the gofer-load on project at a time?
| May be my code does not keep the same order but I payed attention to
| this point. I will check that further.
|
| - may be I could extend Gofer to support multiple project merge
| loading.
|
| So right now I'm stuck and this is sad because freezing a complex
| configuration is really needed.
|
| Stef
|
|
|
|
|
|
