El jue, 05-05-2011 a las 14:17 -0500, Chris Muller escribió: > >> I'm more interested to know the answers to these questions: > >> > >> - How does one deploy an application on Pharo that requires a > >> one-line change to a core system method that is not acceptable to the > >> Pharo gods? > > > > The same tha squeak for changes that aren't accepted/belongs to/are too > > specific to an application. You include them as an *mypackage extension > > in some package of yours and then when the mcz is installed, the > > extension is installed too. That is just monticello as always. > > I'm talking about an override not an extension.
Can't see the difference. Your package just have a method that overrides one method in a core system class. Or am I missing something? > > >> - How does one deploy an application on Pharo that loads code from > >> external web-sites? > > > > Using doIts if necessary. > > Right, dropping down into straight load-script and doing it. Got it! :) Yes, because is the last resort. But most scripts are just pulling dependencies, not resources so if you advocate the scripts just for the fraction of special uses instead of a reified tool, that is a personal decision not really an argument. > > >> - How does one deploy an application on Pharo that requires external > >> graphics, videos, XML or other resources? > > > > Idem. > > Often specific _versions_ of resources go with each specific version > of an application. Now I am maintaining those separately, in separate > places using separate tools. You can have as many doits as you want (they are methods) and each version loaded by the configuration can invoke a given doit to load specific version of your resources. > > I want something to expand the metaphor of an object being > "encapsulated behavior + state" into my deployment system, so it will > be "encapsulated behaviors + resources". Thankfully, even Pharo 1.3 > still supports .SAR files, but no nice GUI to load them, just the > file-manager. :( > > >> - How does one deploy an application on Pharo that requires an > >> object-graph to be loaded internally into the image that was pre-built > >> using another tool (e.g., NOT generated via code)? > > > > Don't understand the example > > A better example. What if I just want something that strips my image > down of lots of code and objects, without leaving any new code loaded? > > It's a rhetorical question, I already know the answer: Create a > Metacello config to host only a load-script (doIt). But I wonder > whether said doIt would be able to "unload itself" when it was done? > Probably could. This is a very specific scenario that most surely is not needed by the 90% of users that metacello is aiming to be useful to. The 10% that need some very restricted loading scenario can have a script that does everything that need. > > > I think it does those things, maybe a second look at the existings > > configurations can clear a lot of doubts. > > The picture seems to be, as long as my app is all just "clean-loading > MC packages", then I can use Metacello within its normal bounds. (OR, > I could just use the standard "lighter-weight" SCM tools; Monticello + > MonticelloConfigurations + Gofer). Yes, but for most maintainers that "clean-loading MC packages" is what we need. For example magma. Is a complex project and even so it doesn't use any of the spoken features so metacello is good enought to load it in Pharo. This argument about scripts vs metacello is like saying that just because you can do the same with assembler when iterating over a list of string you don't need a OrderedCollection. yes you can do the same, but the advantages are greater when working with full objects that with plain text. > > However, if an application requires anything additional: overrides, > resources or special-configurations, then I drop down to the "ultimate > flexbility" afforded by doIt's - which is just load-scripting. Even > then, the resources are not encapsulated as I already said. > > SqueakMap is a repository that hosts load-scripts encasulated with or > without resources. It's perfectly complimentary to all of the other > tools. > > I'm exhausted of talking about this.. Ok, then lets rest it now. Regards -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx