The most frequent use case I have is for pending bug fixes. Imagine this… you find a bug in Pharo that you need fixed to progress on your project, so you fix it. Now, you’ll need the fix to be present anywhere your project is loaded, so what do you do while waiting for the fix to be integrated? You’re obviously not about to manually file in changesets when you have a powerful tool like Metacello! And anyway, you don’t want to have to edit the scripts for your continuous integration server.
I’ve found two ways I like to handle this scenario. I’ll show the (slightly) easier one first.
Method #1 – #customProjectAttributes
This is the method to use for Monticello packages
1. Make sure your configuration has #customProjectAttributes
Depending on the version of Metacello that was used to create your ConfigurationOfMyProject, you may have to add this method (which is easy enough).
In ConfigurationOfMyProject>>project, if you see the following two statements:
"Construct Metacello project" constructor := (Smalltalk at: #MetacelloVersionConstructor) on: self. project := constructor project.
Change them to the following:
project := MetacelloMCProject new projectAttributes: self customProjectAttributes. constructor := (Smalltalk at: #MetacelloVersionConstructor) on: self project: project.
2. Define your custom attributes
#customProjectAttributes will return a collection of symbols that will be added to the Metacello platform symbols e.g. #’squeak4.4′ or #’pharo2.0.x’. The following is for the bug fix example we discussed earlier. The general process is a) declare a condition that let’s you know the fix hasn’t been applied in this image (e.g. a class is not present or DNU a message), and if true, add an attribute declaring that (e.g. #’PharoIssue6300′, as below).
customProjectAttributes | requiresPharoFix6300 requiresPharoFix6382 attributes | attributes := OrderedCollection new. requiresPharoFix6300 := (Morph canUnderstand: #hasKeymapCategoryNamed:) not. requiresPharoFix6300 ifTrue: [ attributes add: #'PharoIssue6300' ]. ^ attributes.
3. Finally, add fixes to your baseline
With this method, they must be packaged with Monticello. See method #2 below if you have to use changesets or .st files
spec for: #'PharoIssue6300' do: [ spec package: 'SLICE-Issue-6300-Detach-keymaping-shortcuts' with: [ spec repository: 'http://ss3.gemstone.com/ss/PharoInbox' ]. spec package: 'VimPharo' with: [ spec requires: #'SLICE-Issue-6300-Detach-keymaping-shortcuts' ] ].
Method #2 – #preLoadDoIt:
This is the method to use for changesets or .st files
1. Add a #preLoadDoIt: to your baseline
spec for: #'common' do: [ spec blessing: #'baseline'. spec preLoadDoIt: #preLoad. ...
2. Define your callback
This method is going to look much like #customProjectAttributes in method #1. The main difference is, since Metacello can not handle file-ins, you will load the code right in this method instead of delegating, as in the following example:
preLoad | shouldFixIssue7294 | shouldFixIssue7294 := (EventHandler canUnderstand: #keyStrokeRecipient) not. shouldFixIssue7294 ifTrue: [ '/path/to/issue7294.cs' asFileReference fileIn. ].
So when would you want to use method #2? For one, you may already have a changeset handy. But the other reason is time decay. In Pharo, for example, because of the rapid pace of development, the package you fixed may have another fix applied first. Now, loading your version may silently replace those changes (this is what happens in the MC browser, I assume Metcello works the same way). I’m actually still figuring out the tradeoffs here for myself. For now, I default to method #1 unless I have a specific reason for #2.
So there you have a simple pattern to conditionally load packages or code files in a Metacello configuration
Hope it helps!