Hi, there are no bars here, just a friendly discussion.  That "style"
was just me having a little fun...  Like you did when you wrote (on
another post):

-  [x] None of the above

I couldn't help laughing, it was funny..

Anyway, so what do you think about the way MaSarPackage addresses the
dependency issue?  With just two methods,

  PackageInfo class>>#packageName
  PackageInfo>>#prerequisitePackageNames

PackageInfo is extended to have dependencies.  MaSarPackage employs
them to relieve otherwise burdensome dependency administrivia from the
developer / publisher.  Should we harvest this functionality out of
MaSarPackage and into Squeak?

If PackageInfo can be responsible for the dependency definitions, SM
can simply focus on its own domain-model, a "catalog" of package
names, their locations, and various helpful attributes like "Full of
bugs" vs. "Stable", etc.  From it's perspective, loading and
configuration are the publishers responsibility (which we will employ
PackageInfo)...



On Thu, Jul 15, 2010 at 9:48 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
> Hi Chris -
>
> I don't want to keep raising bars here but one other issue with SM is lack
> of dependencies. There needs to be *some* way to provide dependency
> information if we want to make it easy to install things. That is, unless we
> assume that anything that has 'real' dependencies is done using Metacello?
>
> Cheers,
>  - Andreas
>
> On 7/15/2010 1:36 PM, Chris Muller wrote:
>>
>> Andreas wrote:
>>
>>> Well, I don't *think* of it as SqueakMap but the comparison is somewhat
>>> appropriate. The main reason why I don't think of it as SM is that SM
>>> wants
>>> to be "all packages ever created for Squeak" but what we need is "all
>>> packages that we've actually tested to work in this image".
>>
>> Every version of every SqueakMap package declares which image version
>> it is for.  In fact, it even includes additional tags such as whether
>> it makes any modifications to that base image.
>>
>> Currently, there is no 4.2 entry in SqueakMap so, regardless of the
>> quality of this tag for past versions, there is an opportunity for,
>> going forward, to simply *test it* before posting it...
>>
>> Not that that should really matter, given usual (MIT) license which
>> completely denies fitness for a particular puporse..
>>
>>> And of course
>>> there are some other differences (like community ownership instead of
>>> individual ownership of the catalog elements)
>>
>> To put this shallow shortcoming to rest, I have a mind to create a new
>> SqueakMap account called, "Community" and announce the password for it
>> here on this list:  "squeak"...
>>
>> We can take charge behind the scenes to add "Community" as a
>> co-maintainer of all existing SqueakMap projects.  We can then
>> announce, on this list, "if you don't want your package to be
>> community-maintaintable, then remove Community as a co-maintainer."
>>
>> Any unrepresented projects will, therefore, not have a advocate to
>> remove it and therefore keep  Community account as a co-maintainer.
>>
>>> but other than that I agree;
>>
>> That's it then?  Cool!!  Let's breakout the SqueakMap!  :-D
>>
>>  - Chris
>>
>>
>
>
>