El jue, 05-05-2011 a las 13:02 -0500, Chris Muller escribió: > Well, I'm 0-2 so far from the replies understanding the point of my > story.. Oh well. > > > The problem with those other repositories is that they are for specific > > uses, as Stef said in other post, the Treated repository is for packages > > integrated in current Pharo. So, of course you could post some package > > there but it wont belongs to there really. > > I don't see getting more use out of something than for what it was > originally intended as a "problem". I was just getting the work done > to quell the complaining for Magma coming from that side.. > > > This workaround it could be better implemented if the package with > > specific changes will be pushed to some dedicated compatibility > > repository where everyone can push every package and use it in their > > install procedures. That would be better. > > Sure, that could be an incremental step but I wasn't in a position at > the time to go lobbying to the Pharo group for a new repository; I > just needed to get Magma done for Pharo'ites. > > Question: When is anything in "Treated" ever "consumed"? If it's not > ever consumed, it's wasting space, so why not delete it?
For the same reason that the Treated repository from Squeak isn't deleted, for historical references. That doesn't means that we should put there what one wants. (well, not that rude, just that as is so easy to create our own repo, isn't well seen if we put packages in others' repos) > > > Now, lets remember that for Pharo at lease, backwards compatibility is a > > "great to have" feature not a "must have at all means" feature. So if > > Actually that describes Squeak's philosophy; they just do it in a > slower, more-incremental nature. > > > Other thing, we really don't like changesets or gofer scripts for > > installing anything on Pharo (even if we really like gofer). Why? > > Because they aren't a package management system. > > Exactly; philosophical instead of practical.. More than philosophical I think. A script can reflect over itself A metacello configuration class can. Text vs class. Unless you put a parser to work, that is extra work. > > >The end result could be the same: the packages are installed in the system, > >that is granted, but > > the capability of Metacello of declaring which other configurations it > > depends on and the one of querying the configuration to see the full > > list of packages to be installed is something that no gofer script, > > installer script or SqueakMap feature can handle right now without > > downloading everything to check. > > Not true. SqueakMap load scripts specify which other prerequisite > configurations are required and merges them, as needed, from SqueakMap > itself. See Magma or Maui as an example. Those prerequisite configs > can be browsed before loading, if desired. Yes, I saw the scripts for Magma and I see check for specific classes to test if they exist in the image (if they are installed): [Smalltalk at: #MagmaTestCase] ifFalse: [ "install other mcz" ] > > 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. > > - How does one deploy an application on Pharo that loads code from > external web-sites? Using doIts if necessary. Or specifying some other repo to fetch mcz things from. A metacello configuration can have any nnumber of origin repositories to fetch mcz from and then install them in the image. For resources like images and so, the doIts can have HTTPClient to download and serialize to the image as needed. Smalltalk at the point of your fingers. > > - How does one deploy an application on Pharo that requires external > graphics, videos, XML or other resources? Idem. > > - 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 But for loading external data that is in a suitable form to load you can use a postLoad doit to open (or download the data) and then bring it into the image, creating objects on the fly. You can load binary data if you want (SIXX, whatever) or text data (XML,JSON,etc) at the end is smalltalk in a doIt doing the work. > > These questions are much more important to me than "it isn't a package > management system". If Metacello could do all of these things, I > might be interested.. I think it does those things, maybe a second look at the existings configurations can clear a lot of doubts. I have a doubt. the metacello configuration can have groups that install specific mcz of the full list of mcz that Seaside have to install just what you need. How will that be made with scripts and SqueakMap? Regards > > Regards, > Chris -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
