The content of the email below would fit in a trimmed version into a
notes page for the Squeak Help System (in-image).

--Hannes

On 2/20/13, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 20 February 2013 02:48, Chris Muller <ma.chris.m at gmail.com> wrote:
>> Thanks for the note John.  I hope you don't mind if I cc the
>> squeak-dev list in my reply.
>>
>>> Hi Chris, a little bug notice which I hope you might be able to help
>>> with:
>>>
>>> I'm trying to get OmniBrowser (incl Refactory, Shout, etc) +
>>> OCompletion installed in Squeak 4.3 (or 4.4), which seems a reasonable
>>> baseline for development -- shouldn't any new release have these
>>> packages validated.  (Plus, what other "5 star" dev tools do you
>>> recommend?  Besides Magma of course :) which I see is in the
>>> SqueakMap, yay).
>>>
>>> After many attempts, I am not able to get OmniBrowser working with
>>> OCompletion in 4.3 (or 4.4 which I totally gave up on and went back to
>>> 4.3 where I got a little closer).  The SqueakMap packages are
>>> conflicting, and several attempts at tracking down custom/patched
>>> installer scripts is not helping.
>>>
>>> Can you advise me a proper sequence starting from the 4.3-All-in-One
>>> image on squeak.org.  And then hopefully forward  the right scripts
>>> into SqueakMap.  Apparently everybody else but me has got their own
>>> private scripts working, no problem :)  but it seems they are not
>>> working off the stock release images.
>>>
>>> By the way, I think it's (way) too confusing to have so many Squeak
>>> distribution points, as discussed at wiki.squeak.org/squeak/5878.  Why
>>> is there SqueakMap + SqueakSource (+ Metacello, + ConfigOf, +
>>> Help.ExtendingSqueak scripts, and the many private scripts and
>>> repositories floating around, etc).
>>>
>>> There should just be 1 master package listing/repository system, which
>>> is usable both for end-users and developers.  Every component/project
>>> should have a stability level (stable, testing, development, sandbox,
>>> throwaway, ... )  It should be an app (e.g.  SqueakMap category
>>> browser), that just filters out various release levels for the end
>>> user installations. I understand this is what SqueakMap is aiming for,
>>> but there seems some disconnect, that few/nobody is forwarding their
>>> material into it (?).  Only a dozen or so validated packages for
>>> recent releases like 4.3, 4.4.  And now there's Metacello, differing
>>> how?  And these ConfigurationOf...  scripts doing what?
>
> Metacello is a dependency management tool. a ConfigurationOf defines
> what subpackages/external libraries something uses, what versions are
> used, and where to find those source artifacts.
>
> It is not SqueakMap (it doesn't care about an ecosystem, only its own
> requirements). It is not SqueakSource/GitHub/whatever. While it itself
> is typically versioned, it describes an application structure.
>
>>> I don't understand why there are so many different tools/repositories
>>> apparently jockeying for "top" package manager.
>>>
>>> In particular the distinction between SqueakSource and SqueakMap seems
>>> broken. Why should somebody have to be manually picking things up from
>>> SqueakSource and replicating into SqueakMap.  Either this should be an
>>> automatic link, or everything should be directly in SqueakMap to begin
>>> with.  Is there any legitimate basis for these being 2 places?  What
>>> is needed to unify/integrate them?
>>
>> You forgot to mention SqueakSource3, and SmalltalkHub, and Git, and...
>
> SqueakSource and friends aren't package managers: they're version
> control systems.
>
> Competition is _good_. The thing that's missing is that bad package
> managers need to _die_.
>
>> Multiple packaging tools is a reality that can't be denied -- so we
>> have to deal with it.  But I don't consider SqueakMap a member of that
>> group.  It's just a Catalog which was intended, from the very
>> beginning, to be precisely what you said (quoting again):
>>
>>> There should just be 1 master package listing/repository system, which
>>> ...
>>
>> Unfortunately during discussions features often get conflated with
>> requirements and cause the discussion and progress to get off track.
>> For example, when you mentioned:
>>
>>> Also desperately needed is better versioning and dependency
>>> declaration and tracking -- is anybody working on that?
>>
>> the very first thing I want to ask is "why" do we need "dependency
>> tracking?"  The answer is we want it so Consume can be a one-click /
>> one-line-of-code affair, not because we need dependency tracking.
>
> Well, we (developers of an application) absolutely require dependency
> tracking because we otherwise can't reproducibly build artifacts. We
> (users) require dependency tracking the moment we wish to load two
> applications into the same image and something goes wrong.
> Environments might well be able to save us from the conflicting
> librari problem, but it's not sufficiently integrated into the system
> yet.
>
>> In 2011 when this very discussion was raging, I captured and
>> documented requirements for the two primary use-cases a Catalog should
>> serve:  Consume and Publish.
>>
>>   http://wiki.squeak.org/squeak/6183
>>
>> I didn't have a lot of time to revamp the whole system, so I designed
>> a set of guidelines that, if merely followed, would allow all of the
>> requirements to be met.
>>
>>   http://wiki.squeak.org/squeak/6182
>>
>> I then made the minor enhancements to the SqueakMap client and server
>> so that following the guidelines would be as painless as possible.
>> The result is, if each Project will take just a few minutes for each
>> just once for each release of Squeak:
>>
>>   http://wiki.squeak.org/squeak/6180
>>
>> then each Author can maintain what you said you want and what I
>> believe the community *needs* -- a master catalog "App Store" of
>> software available for Squeak that _works_.  Something that allows the
>> community to inject power into itself by enabling our work on each
>> other.
>>
>> So, as part of the last few Squeak releases I reached out to fellow
>> community developers publicly and privately to ask them to update and
>> check their SqueakMap entries for the new release.
>>
>> These efforts have not been met with widespread acceptance.  It seems
>> like this discussion is constantly coming up but some folks would
>> prefer spend 10 minutes talking about it again and again than 5
>> minutes to just paste the script into the SqueakMap entry so it will
>> Just-Work(tm) for the the community.
>>
>> I want to be very clear -- the important thing for me is NOT
>> "SqueakMap" (I hated working on it) but having the Consume and Publish
>> (and Collaborate) capabilities working in the community.  Again, I
>> care about requirements being met not what tool is used.  Can't we all
>> just agree we want a Catalog and, until someone else produces
>> something better that can meet the requirements, let's get as much
>> utility out of this SqueakMap bastard as we can.
>>
>> I myself follow all of the guidelines -- when I moved Magma from
>> SqueakSource to SqueakSource3 I didn't have to say a word to anyone
>> because I just updated the SqueakMap entry.  It's a Map.  "Install"
>> just kept working.
>>
>>> Also desperately needed is better versioning and dependency
>>> declaration and tracking -- is anybody working on that?
>>>
>>> Many thanks if you can help me get the OB + OC working.
>>
>> If Colin and/or Levente are willing to provide the scripts for 4.3,
>> 4.4 or trunk, I'm willing to spend the minutes to paste them into a
>> SqueakMap entry and hopefully put this to bed.
>
> And I'll provide CI builds to make sure they continue working in trunk.
>
> frank
>
>> Best,
>>   Chris
>>
>
>