My concern about Metacello has always been that while it is terribly easy to use, it is very potentially difficult to know what to ask it to do. I *think* I have seen signs of improvement and increasing uniformity since I began playing with 1.2. The ConfigurationBrowser probably brought the confusion to light. The ConfiguationBrowser's load latest version command will either force a direct way to do that on all configurations (or at least stand as a reference on how to do it by reflecting on the configuration), but then there is another, bigger, and (I suspect) unsolvable problem: knowing which version to load of any given package. That is a good problem to have (lots of stuff being developed), but we have to acknowledge it. Laurent's Pharo-bloat idea is interesting. While it is not a build target that I would probably want to use, it makes a lot of sense for the Pharo brand to load the latest stable version of just about everything and report on test results. There will still be quirks: when did/does Seaside 3.0 replace 2.8? Of course, one can always start with the core and build anything, but the Pharo Hudson server probably should build things including: (1) recommended Pharo/Pharo-dev - whatever you want to call it, but it's a good starting point for general use; (2) Pharo web, above plus Seaside, Magritte; ... (n) Pharo-package-testing - everything, primarily to see if it builds and to get test results Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, January 08, 2011 9:00 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About preloaded packages
I would also be rather conservative with regard to adding packages that are not developer tools.
If we add XML we should probably also add XYZ. Wouldn't it make sense to add Seaside too? The problem here is not primarily the larger image file size, but the image becomes bloated in general (e.g., search results) and there's a risk of conflicts (e.g., we are using the pharo-dev image, but with our own Seaisde 2.9 version; if the image comes with a preinstalled Seaside 3, we couldn't use it anymore).
It appears to me that preloading packages like XML is just points out that a good package manager is missing.
Yes for example moose people get problem because when they load the latest version of XMLsupport on pharodev1.2 the system barks. While pharo-dev (with tools not frameworks) is an ok image to build systems like moose. Stef