The problem is that my use case is a jenkins job. I want to have something that is the more automatically as possible.
On the other hand, i like tools that support the user to be as free as possible. More if we are taking about tools for developers. In this case, i guess its not bad to have metacello allowing for developers to automatically load last version of every package. I think i have a clear use case here where i have a need that could be perhaps tackled with Metacello and is hard to tackle other way. 2013/6/27 Igor Stasenko <[email protected]> > 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. > >
