Re: [Pharo-project] Cmd-t in OB?
Locked
 
|
Hi,
To me this discussion again raises the point of what I call the "default" case for development :). Lukas, the simplest thing that you can do at this moment is to introduce a "default" version (see those in the ConfigurationOfGlamour/Mondrian/Moose...). This is nothing but your order of packages. Afterwards, you just load that one. When someone wants to hardcode a version, you just spawn this version with the package versions you have in the image. Like this, you have best of both worlds: (1) lightweight management for development, and (2) controlled versioning for releases. Cheers, Doru On 8 Oct 2010, at 17:25, Lukas Renggli wrote: > Yeah, I agree, there is definitely a need for Metacello. > > I suggest to make it easier to use, faster and more lightweight. > Currently it is more the opposite. > > I propose something along Gofer, but for Metacello (I believe somebody > already did something like this?): > > 1. loading the latest stable version must be dead simple > > Metacello new project: 'OB'; loadStable > > 2. loading the latest development version must be dead simple > > Metacello new project: 'OB'; loadDevelopment > > 3. specifying what groups to load must be dead simple > > Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load > > 4. loading should not require to additional infrastructure to be > loaded into a Pharo image (I imagine a server that has all > configurations preloaded and that returns Gofer scripts that can be > executed in the target image) > > Lukas > > On 8 October 2010 17:15, Miguel Cobá <[hidden email]> wrote: >> El vie, 08-10-2010 a las 09:56 -0400, Alexandre Bergel escribió: >>>> ConfigurationOfOmnibrowser project load@*%$LatestCode >>> >>> better in my opinion: ConfigurationOfOmnibrowser loadLastVersion >>> >>> As a metathough, I think we need a unification of how Configuration are defined and used. >>> We have loadDefault in Moose. I often do a ConfigurationOfXX project lastVersion load. You can directly load the baseline. I know this has been discussed many times. But we really need to come up with a simple and efficient way to use configuration. >>> >>> I would also like to have ConfigurationOfXX forEachVersionsLoadAndDo: [:v | ... ], versionsSelect: [:v | ... ], ... >>> >>> Alexandre >> >> There is a long thread in the metacello mailing list where those topics >> are being discussed and Dale is right now working in the new code to >> support them. So if you want to be heard please propose those guidelines >> there so they are taken in account. >> >> >> Cheers >>> >> >> -- >> Miguel Cobá >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "One cannot do more than one can do." |
Re: [Pharo-project] Cmd-t in OB?
|
|
indeed.
So far this is possible. Now dale and mariano were fixing the process to cover all the scenario is a nice and comprehensible way. Stef > Hi, > > To me this discussion again raises the point of what I call the "default" case for development :). > > Lukas, the simplest thing that you can do at this moment is to introduce a "default" version (see those in the ConfigurationOfGlamour/Mondrian/Moose...). This is nothing but your order of packages. Afterwards, you just load that one. When someone wants to hardcode a version, you just spawn this version with the package versions you have in the image. Like this, you have best of both worlds: (1) lightweight management for development, and (2) controlled versioning for releases. > > Cheers, > Doru > > On 8 Oct 2010, at 17:25, Lukas Renggli wrote: > >> Yeah, I agree, there is definitely a need for Metacello. >> >> I suggest to make it easier to use, faster and more lightweight. >> Currently it is more the opposite. >> >> I propose something along Gofer, but for Metacello (I believe somebody >> already did something like this?): >> >> 1. loading the latest stable version must be dead simple >> >> Metacello new project: 'OB'; loadStable >> >> 2. loading the latest development version must be dead simple >> >> Metacello new project: 'OB'; loadDevelopment >> >> 3. specifying what groups to load must be dead simple >> >> Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load >> >> 4. loading should not require to additional infrastructure to be >> loaded into a Pharo image (I imagine a server that has all >> configurations preloaded and that returns Gofer scripts that can be >> executed in the target image) >> >> Lukas >> >> On 8 October 2010 17:15, Miguel Cobá <[hidden email]> wrote: >>> El vie, 08-10-2010 a las 09:56 -0400, Alexandre Bergel escribió: >>>>> ConfigurationOfOmnibrowser project load@*%$LatestCode >>>> >>>> better in my opinion: ConfigurationOfOmnibrowser loadLastVersion >>>> >>>> As a metathough, I think we need a unification of how Configuration are defined and used. >>>> We have loadDefault in Moose. I often do a ConfigurationOfXX project lastVersion load. You can directly load the baseline. I know this has been discussed many times. But we really need to come up with a simple and efficient way to use configuration. >>>> >>>> I would also like to have ConfigurationOfXX forEachVersionsLoadAndDo: [:v | ... ], versionsSelect: [:v | ... ], ... >>>> >>>> Alexandre >>> >>> There is a long thread in the metacello mailing list where those topics >>> are being discussed and Dale is right now working in the new code to >>> support them. So if you want to be heard please propose those guidelines >>> there so they are taken in account. >>> >>> >>> Cheers >>>> >>> >>> -- >>> Miguel Cobá >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > |
Re: [Pharo-project] Cmd-t in OB?
|
|
In reply to this post by Tudor Girba
On 10/08/2010 08:25 AM, Lukas Renggli wrote:
> Yeah, I agree, there is definitely a need for Metacello. > > I suggest to make it easier to use, faster and more lightweight. > Currently it is more the opposite. > > I propose something along Gofer, but for Metacello (I believe somebody > already did something like this?): > > 1. loading the latest stable version must be dead simple > > Metacello new project: 'OB'; loadStable > > 2. loading the latest development version must be dead simple > > Metacello new project: 'OB'; loadDevelopment > > 3. specifying what groups to load must be dead simple > > Metacello new project: 'Seaside'; group: 'Tests'; group: 'Javascript'; load > > 4. loading should not require to additional infrastructure to be > loaded into a Pharo image (I imagine a server that has all > configurations preloaded and that returns Gofer scripts that can be > executed in the target image) Lukas, We are headed in exactly this direction. points 1,2 and 3 are directly covered by a combination of the GoferProjectLoader and new features in Metacello. So your expressions would be recast as something like: Gofer project loadStable: 'OB'. Gofer project loadDevelopment: 'OB'. Gofer project loadStable: 'OB' group: #( 'Tests' 'Javascript'). In addition to the notion of #stable and #development we have talked of the notion of #bleedingEdge. The #bleedingEdge loads the latest version of every mcz file...which may be what you were thinking about when you said #loadDevelopment ... Doru's discussion of a 'default' version and the #bleedingEdge are the same idea. So then we'd add the following expression: Gofer project loadBleedingEdge: 'OB'. As for you point 4, I think that that is a future item. I like the idea, but I think that it is not that simple... One of the more subtle things that goes on when loading Metacello configurations is that the current state of the image (i.e., loaded mcz files) is used to calculate what should be loaded ... if a required project is already loaded and especially if it is already at a later version, that project isn't loaded. If the project is at an earlier version then it is upgraded to conform to required version. On top of this, when a project is upgraded, all of the loaded mcz files are upgraded not just those that are specifically requested... With that said, it should be possible to ship a spec of what is loaded in the current image to a server where the calculation is made and a load directive (basically a Gofer script) could be returned, but there are more moving parts in this than I want to tackle at the moment... Unfortunately, a good bit of my time is being consumed at the moment by a GemStone project, but I fully expect to deliver on the above within the next month or so with an early release available within a couple of weeks as we are still hammering out details ... Dale |
«
Return to Metacello
|
1 view|%1 views
| Free forum by Nabble | Edit this page |