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 > >
