Just adding some comments: - i avoid using loading bleeding edge because it has problems which only humans can solve: - if there are two different branches, not yet merged it may load not one that you want - even if dependencies is ok, it doesn't means that if you load two latest versions of two packages, they will work
so, what i do, is loading a known working config, and then go to monticello and manually picking and loading updated packages. On 27 June 2013 01:27, Dale K. Henrichs <[email protected]> wrote: > > > ________________________________ > > 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 -- Best regards, Igor Stasenko.
