Unloading is a BIG problem, because of package overrides. I tried it a little for Loader and became very frustrated, the whole system become unstable in most of the unload cases (just the easiest ones are passing without problem). I think this functionality just can be achieved with package managers like DeltaStreams or (maybe) MC2... I don't know if Stef work on packages will be useful too. But until something like that cames to Pharo, I would vote "no" to project unload (If my vote counts on something, of course ;) ).
Cheers, Esteban On 2009-12-29 20:02:48 -0300, Dale Henrichs <[email protected]> said: > Unloading isn't supported in Metacello, yet. > > At various points in time in the past I have had unloading working in > Metacello, from the perspective of using the dependency information to > determine what packages should be unloaded and what order to unload > things. But, I thought it was important to get all of the loading logic > complete before attempting to deal with unloading issues. > > I expect that I will be using Gofer to do the actual unloading (as it > is used for the loading), so it isn't the intent of Metacello to handle > overrides any better or worse than Gofer/MC does:) > > Dale > ----- "Alexandre Bergel" > <[email protected]> wrote: > > | Looks good! > | You haven't mentioned unloading. This is an important topic in my > | opinion. > | > | Alexandre > | > | On 29 Dec 2009, at 15:11, Mariano Martinez Peck wrote: > | > | > Hi folks. I just wanted to write down my ideas of the Metacello > | > configurations for our Pharo Images. The idea is to use Metacello to > | > | > manage the dependencies and version of the packages, have a history > | > | > of the releases and be more modular. You will be able to take a core > | > | > image and easily load what you want. We will have a > | > ConfigurationOfPharo and that's what you will probably use. However, > | > | > this conf depends and delegates to another configurations (the conf > | > | > of each package). So, the first step is to make each little conf to > | > | > work, and then, we focus in the pharo one. > | > > | > So....lists of points: > | > > | > 1) I have been writing several configurations so far. One > | > configuration per external project that is loaded in Pharo Dev > | > images. Examples: Shout, OCompletion, RefactoringBrowser, > | > OmniBroswer, O2, etc.. > | > The idea is to implement and be sure each of this conf is working > | > before doing the ConfigurationOfPharo. > | > > | > 2) All configurations will be published here: > | http://www.squeaksource.com/MetacelloRepository > | > This repository is like the ibiblio for maven, or the Universe for > | > | > the apt-get, or similar. In a near future we will have tools that > | > work with this (Esteban Lorenzano is working in Loader for > | example). > | > > | > 3) Each configuration must be PERFECTLY loaded in a Pharo Core image > | > | > without doing or installing nothing. To do this, I have to declare > | > | > properly the dependencies. > | > This mean, that you will be able to take a core image load the > | > ConfigurationOfShout for exameple, or OCompletion and you will be > | > able to load it. Metacello will take care of all the dependencies. > | > You will also be able to install part of the project and not all > | > (for example, only core or core + tests, or whatever). > | > > | > 4) I started with the Dev packages. We will do this test first to > | > see if Metacello really help us in our project. If this goes well, > | > | > then, in a second step, we will take care about the Web images. > | > > | > 5) I started with the 1.0 Dev packages. 1.1 is unestable and several > | > | > external packages even don't load in it. So, will do 1.1 in a second > | > | > step. > | > > | > 6) As there were no versions of Metacello in all the external > | > projects, I started with 1.0 in ALL. Shout 1.0, OCompletion 1.0, RB > | > | > 1.0, etc. This has nothing to do with Pharo 1.0. They are just the > | > | > version number. And after this is released, we really need PLEASE, > | > | > that the maintainers of those packages also creates the following > | > versions for them. > | > > | > 7) I took as a base, the versions of the 10496 image. I have been > | > using this image since in was release, 12 hours a day, and seems to > | > | > be very stable to me. I mean, the version 1.0 of > | > ConfigurationOfPharo will be like the 10496 image. When everything > | > | > is done and working, create a new image will be very easy. > | > > | > 8) We need some features from Metacello which are in the todo list. > | > | > So, we will have to wait a bit for them. > | > > | > OK, that's all. What do you think? > | > > | > Soon I will send an email for the configurations of all projects and > | > | > will ask for help and feedback from their developers. > | > > | > Cheers, > | > > | > Mariano > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > [email protected] > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | > | -- > | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > | Alexandre Bergel http://www.bergel.eu > | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > | > | > | > | > | > | > | _______________________________________________ > | Pharo-project mailing list > | [email protected] > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
