Take care: lengthy post.

Myself wrote:
>Your Installer code would ALWAYS load the latest of each monticello
>package in the repo.

One additional thing to note here: as a developer on a project you
may want exactly that: not load a specific version but load the 
LATEST package versions available from a repository to be "up to date".

This is easily done by loading a baseline instead of
a released version - so you can have the same result as with an 
"installer script without versions" here. 

In our example if you would load '1.0-baseline' you would get the latest 
packages released before the split of the core package was done and if 
you load the '1.1-baseline' you will be up to date on the project
(since it is the last baseline).

Igor wrote:
>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.

I know that - I dont say you can't do this with Installer. But think
about the scenarios you would end up with a similar scheme:

   MyConfig>>installV10Latest    -> similar to the #baseline10: 
   MyConfig>>installV10          -> the same as #version10
   MyConfig>>installV11Latest    -> similar to the #baseline11:
   MyConfig>>installV11          -> the same as #version11

So you would end up with the same we currently have in Metacello.

Metacello does just one thing more: it separates the dependency description/load
order description (baseline) from the version of the packages the loader should use. 

If you do it with your Installer scheme you would have the load order coded in all your 
four #instalXXX methods. In Metacello the order is only in the two baseline methods.

>So, please tell me again, why i should use Metacello for this?

You could always write a script (using Installer, Gofer, whatever),
but does it make sense? To automate and unify things you would have to agree on a 
few basics for the descriptions. 

So wouldnt it be better do describe dependencies and version to use 
in a declarative way so we could have tools to manage it.

As in Linux - you could provide a shell script for the installation of your
program OR you create a description that is usable by the package management
system. Anybody who knows how to use "apt-get" now also knows how to get
you package then.

But here are some more arguments to at least have a look at Metacello:

  a) because in any case you would end up with a similar scheme to satisfy 
     the scenarios (with Installer or any other implementation)

  b) because it provides a basic scheme already (depending on your own history 
     baselines and versions may be known to you) 

  c) because it provides a reusable format and I can describe dependencies not
     only between Monticello packages for your own project but also 
     between Metacello configurations. So you could manage "inter-project"
     dependencies.
  
     This is crucial that one project can base its work on a specific milestone
     of another. In my code I can rely on version 1.1 of MyDatabaseDriver 
     which itself relies on version 1.2 of FFI, ... 
     
     (Again: You can also do this with Installer scripts but you would have to 
     define rules people would have to follow).

  d) While you "hard code" an Installer script the Metacello description uses
     a "spec" object. Such a spec could be managed with tools.

  e) Metacello is not Squeak specific: it already works in Glass, Pharo and
     Squeak trunk. There is work going on on having it in older squeak releases too.
     
     With a common PMS we could easily share and exchange code - at least the
     one that is not bound directly to the ST system it is implemented.

     A PMS should also help to manage differences here. There is some basic
     support for that in Metacello. You could write a spec for Pharo and one for Squeak 
     if you like.

  f) Metacello is already MIT, there is a google project for it and it
     is actively maintained. 


I dont say that Metacello solve all problem yet - but at least a few and it
is open for new ideas. So we all should have a look at it. Nothing more!


Keith wrote
>The author will not have tried and tested the code in every context,  
>so really he doesn't know what is actually needed to load. 

It's obvious that the author is not able to to test in every context. Will an app
developer for Linux test any distibution that's out there ... no. He just makes a release 
for the most common ones.

>It cant be because a kernel image will not have Monticello loaded, nor  
>will it have network, or compression even.

Shouldnt the kernel image have either a minimal package management system or 
at least boostrap code to load one?

>[SNIP - removed lot's of "my stuff does it better" mumbling]

OK, again. I still waiting for the proof that you can do better. As I said on
the vm-dev list, show me on the Seaside/MetaSource example how to do it with your 
tool chain. I'm still open to it.

Unfortunately you were not yet able to do so! If you cant explain/document or use your own 
technology to demonstrate to others how to use them then you may be a good developer
but you waste your time since nobody will ever dive into your stuff or buy it.

>I have come to the conclusion that having dependency  
>management is not the way to go

No comment

>You just scared me, a poor mediocre coder, imagining a future when the  
>loading tools have more code and classes in them than the system itself.

You could not deny the fact that we need a description of existing packages, their 
dependencies and versions that fit together to make up milestones of project 
releases that can build on each other.   

I dont care about the internals of Metacello - you can easily unload it after
it has it's job done. ;)

We can even transform the spec descriptions into other formats, write new
or better tools on it...


>The problem I see as a casual observer looking at  metacello is that  
>if that is our "simple solution" and it doesn't do quite what I want,
>
>I now have the same opinion of Monticello

There is always something better. But you cant change the whole world in one
day. You need a pragmatic look what is already there and can be used to get the
next job done.

>I have sat starting for 4  years at horrible code in the kernel, and it is still 
>there. 

OK, so why dont you change it? If I remember correctly it is now possible to 
contribute to trunk. It may not be the best process - but at least it is possible.

If it is too complicated since you need more access/rights whatever then show
us how to use your ideas in Cuis and let the community decide...


Andreas wrote:
>we do indeed need a package management system. Urgently.

+1

>with the eyes of what I'd expect to see in a package *management* system

I never claimed that it is finished or the best thing ever invented.
It solves a few problems and if we all dive in a little bit we may find
or solve all the things that need to be adressed.

>What's worse, that ConfigurationOfXXX code has specific 
>dependencies on other code (Metacello) which it first loads and that 
>again has other dependencies (Gofer for example).

This is just to bootstrap, the spec description is unrelated to Gofer.

That the spec is defined in code is not a problem for me, since I can easily 
transform it to other formats (XML, whatever). It is one form of a description.

>As far as I understand, Metacello doesn't know what it has loaded.

Thats not true:

  ConfigurationOfHelpSystem lastMetacelloVersionLoad 

You can even recreate the spec easily:

 (ConfigurationOfHelpSystem project version: ConfigurationOfHelpSystem lastMetacelloVersionLoad key) spec 


>Well, there's just no support for unloading,

I'm sure it will support unloading in the future. Did you see  MetacelloSpecLoader>>unload

>I'm looking forward to reevaluating Metacello at this point again.

That does not anymore sound like your first statement ;)


Igor wrote:
>Keith, may i ask you to illustrate us a use of S/P for the same
>scenario, decribed by Torsten in post above?
>I think it would be an interesting comparison.

I already asked him to reproduce "ConfigurationOfMetaSource" from
http://www.squeaksource.com/MetaSource as an example for me 
to really compare. See [1]

Anything I got was a simple response that:

   "Sake/Packages does all that." and "(Package named: 'Seaside') latest load."

Crazy! I dont want to offend him but he is really bad in selling his own
stuff to others...

Bye
T.

[1] http://lists.squeakfoundation.org/pipermail/vm-dev/2010-February/003871.html



-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01