Allright ... I'll add a test case covering #bleedingEdge loads (perhaps not today...) and let you know if it's already functional or not ... if not I'll plan on getting it supported ...
Dale ----- Original Message ----- | From: "Guido Chari" <[email protected]> | To: "Pharo Development List" <[email protected]> | Sent: Thursday, June 27, 2013 10:23:33 AM | Subject: Re: [Pharo-dev] Metacello doubt | I'm in. | 2013/6/26 Dale K. Henrichs < [email protected] > | | | From: "Guido Chari" < [email protected] > | | | | | | To: "Pharo Development List" < [email protected] > | | | | | | 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 |
