I have a baseline in my github repo for a tool I am making and I have included the pillar development dependency via an ugly hack , whats it the proper way of doing this ?
|
I think I have figured it out after some googling if I can improve it I am open to suggestions but for now it seems to work On Sun, Oct 23, 2016 at 4:46 PM Dimitris Chloupis <[hidden email]> wrote:
|
In reply to this post by kilon.alios
Dimitris,
This is your baseline method and I'm not sure what you consider "an ugly hack": baseline: spec <baseline> spec for: #'pharo' do: [ spec package: 'Octopus' with: [ spec requires: #('Pillar') ]; configuration: 'Pillar' with: [ spec repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main'; version: #'development' ] ] Is it the fact that you have to include #development instead of #stable in your baseline? If so , you can make a pre-load decision to use the development version of Pillar by using a Metacello lock: Metacello new configuration: 'Pillar' version: #development; repository: 'http://smalltalkhub.com/mc/Pier/Pillar/main'; lock. Then you can change your baseline back to using #stable or whatever and when you load the Octopus project, using 'Metacello new', the #development version should be used ... Or is there something else that you consider "an ugly hack"? Dale On 10/23/16 6:46 AM, Dimitris Chloupis wrote: > I have a baseline in my github repo for a tool I am making and I have > included the pillar development dependency via an ugly hack , whats it > the proper way of doing this ? > > https://github.com/kilon/Octopus/blob/master/BaselineOfOctopus.package/BaselineOfOctopus.class/instance/baseline..st > > |
Well I started by using Gofer instead of spec configuration for Pillar. That is what I regarded an ugly hack but with some googling I found a solution via spec configuration and was not sure if it was a good solution hence why asked. The intention is indeed to load Pillar development, mainly because I wanted to take advantage of the Pillar Editor but if it proves too unstable I can always revert back to stable. Thanks indeed the first code fragment is what I wanted to make sure it works well. Will keep lock in mind for the future. Thanks again. Curious question: let say that the spec configuration in first code fragment fails to load for various reason, is there a way for metacello to detect the fail and add something to the baseline , let say the stable version of pillar, so if it sees that the development version of pillar fails to load it falls back to loading the stable version instead ? Essentially I am asking here about metacello exceptions. On Sun, Oct 23, 2016 at 8:26 PM Dale Henrichs <[hidden email]> wrote: Dimitris, |
On 10/23/2016 11:08 AM, Dimitris Chloupis wrote: > > Curious question: let say that the spec configuration in first code > fragment fails to load for various reason, is there a way for > metacello to detect the fail and add something to the baseline , let > say the stable version of pillar, so if it sees that the development > version of pillar fails to load it falls back to loading the stable > version instead ? > > Essentially I am asking here about metacello exceptions. > I haven't done any work with respect to dynamically changing the project version that is loaded with the exception of lock handling. If you look at the subclasses of MetacelloScriptNotification and MetacelloProjectSpecScriptNotification you will see the notifications that are used to implement the fundamentals of lock handling and I suppose that it would be possible to build a MetacelloScriptEngine that gave a developer some explicit control over project spec lookup, but doing so in response to unspecified load errors could be a bit dicey ... Presumably, one could write an error handler that caught load errors and then manipulated the project locks to do something like you are suggesting ... Dale |
Ok no problemo, Metacello is pretty reliable I was just curious. Thanks :) On Mon, Oct 24, 2016 at 9:50 PM Dale Henrichs <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |