[squeak-dev] Loading Xtreams-Xtra into trunk broken

Chris Muller asqueaker at gmail.com
Thu May 5 22:04:55 UTC 2011


There are so many holes in what you're saying, but I'm out of gas.  Sigh..

> A has no dependencies, so its script (scriptA) just install its mcz
> files.

Right.

> B depends on A and a script for be "checking" that A exists before
> installing B. It can have a few implementations:
> a) uses the scriptA to install A
> b) installs the mcz from B that think it needs, but leave without
> install other mcz that doesn't need right now
> c) copies the scriptA into scriptB (copy & paste nightmare when scriptA
> is upgraded)

(a) is the answer, of course.

> Then comes C maintainer and doesn't know about scriptB it only know that
> it needs A and B in order to work. He has a hell lot of options:
>
> 1) scriptC install what it thinks it needs from A and from B, leavin
> some mcz out.
> 2) scriptC uses scriptA and uses what it needs from B (because B is a
> direct dependeny and know what really needs and what not. Not the same
> for A that he doesn't really know and to not fail better install
> everything)
> 3) scriptC copies scriptA and scriptB into scriptC (again copy&paste
> hell)
>
> Now you have 3*3 = 9 ways to install C. What a mess.

The only thing that's a mess is how you're trying make something so
simple into something so complicated.

  A exists ifFalse: [ run Script A ].
  B exists ifFalse: [ run Script B ].
  load elements of C.

Done.

> Metacello instead, permits a configuration to "declares" what it need
> "directly" and then it goes and "fulfill" the requiremets for it.
>
> So with metacello. supposing that metacelloConfigA exists, then
> maintainer of B can define metacelloConfigB that depends on A.
> Lastly, maintainer of C creates metacelloConfigC and "only" depends on
> metacelloConfigB and *don't* care about what B depends on. It let B to
> decide and metacello to fulfill.

Whatever..  Magma is a prime example of your A, B, C.  Magma depends
on MaClientServer depends on MaBase.

> So I think that this whole SqueakMap approach is not going to scale well
> in the long term when relying on custom-made scripts without
> standarization or order.

"Standardization" or "order", huh?

Putting everything into one SqueakSource project; now _there's_
something that is not going to scale well..

Bye..



More information about the Squeak-dev mailing list