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 <[hidden email]> wrote: > On 20 February 2013 02:48, Chris Muller <[hidden email]> 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 >> > > |
Free forum by Nabble | Edit this page |