[squeak-dev] Re: OmniBrowser + OCompletion in Squeak 4.3 / 4.4 ? And Cacophony of Package Systems ...

Frank Shearar frank.shearar at gmail.com
Wed Feb 20 10:30:55 UTC 2013


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
>


More information about the Squeak-dev mailing list