On Jul 31, 2004, at 10:00 AM, goran.krampe at bluefish.se wrote:

>> SqueakMap, today, is a catalog of everything.  You can expect to go to
>> SqueakMap and find any package that exists.  However, you can't really
>> expect to click on an item in SqueakMap and have it install 
>> successfully
>> along with any dependencies it needs.
>
> Of course not - because it doesn't *have* dependencies yet. Pretty
> obvious to me.
>
>> That's fine for a catalog of everything.
>>
>> In a one-click installer, though, you should not even *see* stuff that
>> cannot be installed.
>
> This is just filtering, trivial IMHO.
>
>> You should not have to answer questions about
>> different versions of stuff, unless you have explicitly asked to get
>> into the nitty gritty.  Every package version you see in the tool,
>> should be consistent with whatever universe you are operating in.
>
> Fine, again filtering and preferences.

I think you're missing a key point here, or at least dismissing it as 
less important than I think it is.  When you say "just filtering", it 
sounds like you're talking purely about UI: which packages (and package 
releases) are displayed to the user in the package loader.  But what 
Lex is saying is deeper than that: first, that these "filters" will 
affect which versions of required packages are used to fulfill 
dependencies by default (so it doesn't just filter what the user sees, 
but in some sense what the dependency engine sees as well), and second, 
that because of this behavior you can get away with a much simpler 
dependency system - because it's the filters that are doing most of the 
narrowing down to a particular release, and so the dependency engine 
doesn't have to.

That's not a trivial thing, and it's not just a UI layer on top of the 
SM mode: it's a very different way to think about the dependency model, 
and I think you should take it into account.  FWIW, it also aligns 
pretty well with the direction I've been meaning to take 
Monticello-level dependencies/tags...

Avi