A GUI is fine, but Esteban appears (IMHO - only he can speak for himself and 
his plans) to be tackling the void of a scriptable package system.  By analogy 
to my evolving home away from Redmond, a graphical package manager is great 
when I want one thing; it starts to break down when somebody is telling me how 
to install all the packages I need to compile something from source, in which 
case I want a shell script with a bunch of apt-get lines.

Esteban's code is probably going to be of greatest value to someone who begins 
to use Pharo and then is faced with the need to load many external packages 
into future images.

One of the few things that Microsoft has gotten right over the years is COM 
versioning; it supports versioning by pointedly not supporting it.  Want a new 
version?  Make a new interface.  That is exactly how I approach my own code.  
The only time I ever have to mess with it is to periodically make sure I have a 
loadable copy of my work, and (the big one) when it comes time to build a new 
image.

The things that need to be done are:

(1) find all code that I appear to have touched, so I won't loose work;
(2) save all of my work in ONE STEP (maybe fewer<g>)
(3) provide ONE THING that I load into my next image, and it
    loads everything else in ONE STEP, with the ability to
    break it down if things go wrong.

I don't care about version of my code; I just need to save its current state 
and load that into the next image.  For external packages, I hope not to care 
much about versions.  I might want to specify a given verion of Seaside, and 
after that, I will typically want the latest of a given list of packages.  When 
somebody lets me down, I will want to override that version in specific cases.  
My evolving solution is in the form of Migrate, which I hope to be able to 
simplify over time thanks to Loader.

GUI tools usually make it easy to spend a long time doing a bunch of small 
steps, such that what could be a simple task turns into an error prone 
nightmare.  In general, GUIs are great for tinkering, and command lines and 
scripting are good for automation.  We can have all the GUIs we want, but 
please note the importance of scripting.

Bill



-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Tudor Girba
Sent: Saturday, May 08, 2010 10:48 AM
To: [email protected]
Cc: Pharo Development
Subject: Re: [Pharo-project] [Metacello] We need a UI for Metacello/Loader

Hi,

Could you detail a bit the requirements?

Cheers,
Doru


On 8 May 2010, at 16:53, Mariano Martinez Peck wrote:

> Hi folks. First of all let me clarify that all this email is though 
> for new comers.
>
> I think Metacello is a wonderful project and that's why we are 
> adopting it in Pharo. I know Metacello has it's own UI:
>
> http://code.google.com/p/metacello/wiki/MetacelloTools
>
> I also know there is Metaceller done by Doru.
>
> But I think that the features Esteban Lorenzano implemented in       
> GoferProjectLoader are a MUST for a new comer. You can read them here:
>
> http://www.smallworks.com.ar/en/community/GoferProjectLoader
>
> Now...he doesn't plan to do a UI for that. My question if it would be 
> a good idea to "extend" Metaceller or Metacello-OB so that to uses 
> GoferProjectLoader features. Not necessary for Metacello 1.0 but maybe 
> for 1.1. I think this is important, at least for Pharo. We don't have 
> Universe neither SqueakMap anymore.
>
> Cheers
>
> Mariano

--
www.tudorgirba.com

"The coherence of a trip is given by the clearness of the goal."





_______________________________________________
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

Reply via email to