hi goran

I was waiting more than one hour in a doctor room this morning so I 
could not
stop my mind to think. I would like to understand how script works with 
package.

You said that the package itself does not have dependencies to other 
packages but that a
script knows that. So my question is how do I know that when I load a 
package I should run a script?

Every times I will publish a package I will have to produce a 
configuration map (script) else other people will not
be able to use my code or have to guess the dependency.
So how this is different that having the package knowing what it should 
load.
Do you plan to have one config map per package?


Stef



On Mardi, nov 18, 2003, at 10:07 Europe/Zurich, ducasse wrote:

>>
>> ...and in other ways to. But this time a specific *release* is 
>> specified
>> so the script will load the exact same file every time.
>
> excellent. this was more than needed.
>
>> As long as the
>> maintainer doesn't *change* that file of course.
>
> sure
>
>>  I did think about
>> immutability but after input from other prominent Squeakers have 
>> decided
>> to instead rely on people *not abusing this*.
>>
>> Ok, now back to your question - bundles. Using my intuition I guess 
>> that
>> a "bundle" is a file actually *containing* multiple packages instead 
>> of
>> "referencing them" like the load script above.
>
> Not necessary. Conceptually you can say that a bundle is composed of 
> packages
> but internally you can code that the way you want.
>
> The advantage that composite gives you is a uniform interface to 
> manipulate bundle/script
> and package. There is a difference between concepts and implementation.
>
> At the end you want to load an application (may be using a script but 
> this is file oriented)
> an object that knows how to build itself picking the right versions of 
> his elements.
>
>>  Is that right? In that
>> case I *do NOT want them*. :)
>
> I did not mean that.
>>
>> Because it goes straight against my coming plan for dependencies.
>> Dependencies should IMHO be specified *outside* of the packages in the
>> form of independent objects I like to call *package configurations*.
>
> package configurations seems to me like envy config maps (apparently 
> the problems
> in envy config maps is that you could not reference to subapplication 
> versions) but
> I should ask joseph that kind of ugly envy stuff. your package 
> configurations look also as bundle in VW.
> I'm not expert in the fine pros and cons of both approaches but I hope 
> you know them.
>
> My point is that I already have my own script to rebuild my small 
> system but we cannot ask every body to
> rehack the same in his corner so any decent package mechanism has to 
> have version identification and it should work well
> else all our efforts to modularise squeak will fail. It was for 
> example fun to see andreas wondering how
> to be able to load old package in Squeak. There is a simple scalable 
> solution to that problems: packages
> with version and configuration you know that I'm sure.
>
> So I'm waiting to see SM 2
>
> regards, Göran
>>
>
>
>