El lun, 22-02-2010 a las 03:32 +0200, Igor Stasenko escribió:
> On 22 February 2010 02:02, Torsten Bergmann <astares at gmx.de> wrote:
> > Andreas Raab wrote:
> >> BTW, for people who'd like to install HelpSystem with Installer instead
> >> of Metacello, use this:
> >>
> >
> > NOOOO!!!!!
> >
> > As Yanni already answered to you: the Metacello code would load version '1.0' of the help system -
> > so it loads a A CLEARLY DEFINED MILESTONE with packages that are intended to
> > work together and which is also intended by the author for others to use.
> >
> > If I later define a '1.1' or '1.2' milestone any user could decide if he is
> > ready to adapt his own code (if it is based on my project) to my new
> > releases or if he (for whatever reasons) continues with one of my old releases, like 1.0.
> >
> > Your Installer code would ALWAYS load the latest of each monticello
> > package in the repo. So depending on the time you run it (and the state
> > of the repo) you get DIFFERENT results and may break code. Thats horrible!
> >
> 
> You maybe missed one thing: Installer can load a specific version of
> package(s).
> It is an 'extra' feature which picks the latest version, but you may
> not use it, if you don't want it.

Yes but the less you direct the users to specific versions of packages
the better. And this works only for a package that has just a handful of
packages. But if, as Seaside or as Magma that list is several dozens
lines bigger. For example, for Magma you have:

'WriteBarrier' with: 'WriteBarrier-pmm.26';
'Collections-BTree' with: 'Collections-BTree-lr.68';      
'Ma exception handling' with: 'Ma exception handling-cmm.32';
'Ma base additions' with: 'Ma base additions-cmm.149';
'Ma proxy support' with: 'Ma proxy support-cmm.40';
'Ma Squeak domain' with: 'Ma Squeak domain-cmm.28';
'Ma contextual search' with: 'Ma contextual search-cmm.29';
'MaFixedWidthReport' with: 'MaFixedWidthReport-cmm.7';
'Ma special collections' with: 'Ma special collections-cmm.101';
'Ma traverse object graphs' with: 'Ma traverse object graphs-cmm.29';
'Ma Statistics' with: 'Ma Statistics-cmm.21';     
'Ma object serialization' with: 'Ma object serialization-cmm.220';
'Ma client server' with: 'Ma client server-cmm.214';
'Ma Armored Code' with: 'Ma Armored Code-cmm.144';
'Magma client' with: 'Magma client-cmm.446';
'Ma object serialization tester' with: 'Ma object serialization
tester-cmm.27';       
'Magma server' with: 'Magma server-cmm.382';
'Ma special collections tester' with: 'Ma special collections
tester-cmm.12';
'Magma tester' with: 'Magma tester-cmm.352'

Then the installer script is harder to read and manually generate. And
also to diff if you happen to found two versions in the mailing lists.
Maybe just 1 package got a bug fix but the others are the same versions.
The user could wrongly use the wrong package list because it appear to
be the same.


> 
> 
> > By using Metacello a projects author can make specific versions/package configurations available to others and afterwards commit new code to the repo without affection others.
> >
> >> This installs in a fraction of the time and space.
> >
> > Hey, installer is just a loader. Metacello is a package management
> > system!!! Ever worked with Envy or Maven in Java, ...?
> >
> > Without Metacello (or a comparable package management system) we
> > will NEVER SCALE projects or allow that they develop independent
> > from each other without breaking each other! Especially when
> > they are managed outside of the image - and I think that's our goal:
> > a small kernel image and external projects/packages that could be
> > loaded (and that fit together to work and could be based on another).
> >
> > Metacello does the minimal thing to manage that and even if it
> > may require more work (especially on tools) it does a fairly good job
> > already. You just have to learn about it and about modularity.
> >
> >
> > Think of the following scenario:
> [snip]
> 
> Strange thing but with Installer i could implement same scenario(s).
> So, in same way, one could implement
> 
> MyConfig>>installV10
> MyConfig>>installV11
> etc
> and inside of these methods, put a code which loads specific versions
> of packages.
> 
> So, please tell me again, why i should use Metacello for this?
> 

Yes you can do that, nobody denies it. But I will do in my way, maybe
using 

'someur' asUrl retrieveContents

an some more magical incantations and then direct users in a mail to the
mailing list to evaluate some other incantation.

Then user C makes their other personalized script to load its packages.

And so and so and so.

There isn't a standard way to load things, just multiple, incompatible
ways to load things with the same *my own because I can* way of doing
it. That isn't having a long term goal of a real integrated squeak/pharo
distros.
Besides, your script doesn't manage dependencies, and if does, it has to
install every dependency. And if some package is already installed in
the image, then your script need to check if the dependencies are
already installed. So, isn't as easy and you are in fact redoing the
work Metacello can do for you.

For example, for my project depends on Magma and Seaside. Using your
method, I would have to build a script that installs Seaside, and before
that install Magma, and before that OSProcess and WriteBarrier. But to
install Magma I would need to know what versions of WriteBarrier works
correctly with Magma, and what versions of Scriptaculous works correctly
with Seaside. That is to much.
With ConfigurationOfMagma and ConfigurationOfSeaside, my package only
list that two packages as dependencies, and I don't care about what they
need as dependencies. That is not my problem. Is theirs. So my install
script is as small as can be. In fact this is the script I use to build
my development image:

"Development image"

"Azteca"
Gofer it
  directory: '/home/miguel/proyectos/azteca/mc';
  package: 'ConfigurationOfAzteca';
  load.

((Smalltalk at: #ConfigurationOfAzteca) project version: '0.1')
  load: 'DevelopmentImage'.

"Save as development.image"
SmalltalkImage current saveAs: 'development'.
SmalltalkImage current snapshot: true andQuit: true.


And this the script I use to build my deployment magma image:

"Magma image"

"Azteca"
Gofer it
  directory: '/home/miguel/proyectos/azteca/mc';
  package: 'ConfigurationOfAzteca';
  load.

((Smalltalk at: #ConfigurationOfAzteca) project version: '0.1')
  load: 'MagmaImage'.

"Start the RFB server in display :0"
(Smalltalk at: #RFBServer) current
  setFullPassword: 'secretpassword';

"Save as magma.image"
SmalltalkImage current saveAs: 'magma'.
SmalltalkImage current snapshot: true andQuit: true.

Simple.

BTW, do you use windows, mac or linux?

> >
> > Sorry for the long post - but I hope I was able to wet your appetite towards modular Smalltalk.
> >
> > Bye
> > T.
> >
> > [1] https://docs.sonatype.org/download/attachments/1999021/pom-dependency-graph.png?version=1&modificationDate=1212678465631
> >
> > --
> > NEU: Mit GMX DSL über 1000,- ¿ sparen!
> > http://portal.gmx.net/de/go/dsl02
> >
> >
> 
> 
> 

-- 
Miguel Cobá
http://miguel.leugim.com.mx