----- Original Message ----- | From: "Guido Chari" <cha...@gmail.com> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, June 26, 2013 2:49:09 PM | Subject: Re: [Pharo-dev] Metacello doubt
| I understood. Thanks for the answer Dale. The drawback in this case | is to specify a particular dependency to AsmJit in my configuration. | Also, perhaps is the right way since i realized i have a particular | dependency on it. | But this discussion makes me thing a little and so i have a new | question. | Form what I (mis) undestand from Metacello, when asking for a | bleedingEdge version it loads only the baseline that specifies | packages and then last version of every package specified there. | As in the projects referenced on the baseline there is no need for | specifying a version, and that's the case of nativeBoost | configuration, wouldn't it be interesting to have some behavior (i | mean i new method for loading like loadDeepSymbolic:) that not only | load the symbolicVersion of the package asked, but also propagate | that symbolicVersion (bleedingEdge in this case) to all the | dependencies that don't specify a concrete version? | Guido. Guido, With the Metacello Scripting API[1] I've taken a slightly different tack, but I think that it gets you to the same place. I am a big fan of deterministic loads, but I know that from a practical point of view developers need to have a certain amount of control over exactly what gets loaded into their DEVELOPMENT environments and they need to be able to exert this control without having to resort to editing configurations to match their specific requirements. I have accomplished this by arranging for a Notification to be signalled whenever a project is referenced during a load. The developer can use one or more of the onUpgrade:, onDowngrade: and onConflict: clauses in their load scripts to exert fine control over what happens on a project by project basis ... For your specific use case, I would think that you would want to use the `lock` command[2] and specify that you want to `lock` the projects (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if I've got test cases for symbolic versions, but if you are seriously interested in taking the Scripting API for a spin, I'd be willing to write some additional tests using the #bleedingEdge symbolic version (if not already covered) and validate this use case... I am entering a phase where I will be doing some work on getting FileTree and Metacello up to snuff for Pharo3.0 so this would be a good time for me to add some test cases in anticipation of having some interested users ... I haven't released the Scripting API, because I need to have real users with real use cases take the API for a spin and validate the API. The Scripting API can be loaded into any version of Pharo/Squeak/GemStone and I think the Scripting API is (or will be) available in Pharo3.0. I'm looking forward to getting feedback as to how the API stands up to real use ... So let me know if you are interested in being another Scripting API guinea pig:) Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md [2] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#locking
