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? > > 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... 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. 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. Best, Chris |
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 > |
Am 20.02.2013 um 11:30 schrieb Frank Shearar <[hidden email]>:
> 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. > […] Here is my not too serious comparison chart for The Things to Load Code. Pkg install frontend Package manager Version management Repository -------+-----------------------+-----------------------+-----------------------+--------------------- Squeak SqueakMap Metacello Monticello SqueakSource/Smalltalkhub Python pip eggs ? (eg) hg (eg) bitbucket JS npm npm (eg) git (eg) GitHub GLASS (Metacello api) Metacello Monticello GitHub/Squeaksource3 Debian aptitude dpkg / / All four categories are necessary and serve very different purposes. Note this list is only examples. Note that there may(and should) be certain overlaps the farther right you get. Best -Tobias |
Tobias,
helpful chart to get the big picture. Thank you. --Hannes P.S. How would the Java row look like? :-) On 2/20/13, Tobias Pape <[hidden email]> wrote: > Am 20.02.2013 um 11:30 schrieb Frank Shearar <[hidden email]>: > >> 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. >> […] > > Here is my not too serious comparison chart for The Things to Load Code. > > Pkg install frontend Package manager Version management Repository > -------+-----------------------+-----------------------+-----------------------+--------------------- > Squeak SqueakMap Metacello Monticello SqueakSource/Smalltalkhub > Python pip eggs ? (eg) hg (eg) bitbucket > JS npm npm (eg) git (eg) GitHub > GLASS (Metacello api) Metacello Monticello GitHub/Squeaksource3 > Debian aptitude dpkg / / > > All four categories are necessary and serve very different purposes. > Note this list is only examples. Note that there may(and should) be certain > overlaps > the farther right you get. > > Best > -Tobias > > > |
But we are digressing.
I loaded OmniBrowser into 4.4 in December http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-December/166810.html The question is now how to add OCompletion. --Hannes On 2/20/13, H. Hirzel <[hidden email]> wrote: > Tobias, > > helpful chart to get the big picture. > Thank you. > > --Hannes > > P.S. How would the Java row look like? :-) > > On 2/20/13, Tobias Pape <[hidden email]> wrote: >> Am 20.02.2013 um 11:30 schrieb Frank Shearar <[hidden email]>: >> >>> 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. >>> […] >> >> Here is my not too serious comparison chart for The Things to Load Code. >> >> Pkg install frontend Package manager Version management Repository >> -------+-----------------------+-----------------------+-----------------------+--------------------- >> Squeak SqueakMap Metacello Monticello SqueakSource/Smalltalkhub >> Python pip eggs ? (eg) hg (eg) bitbucket >> JS npm npm (eg) git (eg) GitHub >> GLASS (Metacello api) Metacello Monticello GitHub/Squeaksource3 >> Debian aptitude dpkg / / >> >> All four categories are necessary and serve very different purposes. >> Note this list is only examples. Note that there may(and should) be >> certain >> overlaps >> the farther right you get. >> >> Best >> -Tobias >> >> >> > |
In reply to this post by Hannes Hirzel
Pkg install frontend Package manager Version
management Repository -------+-----------------------+-----------------------+-----------------------+--------------------- Java Maven Maven (eg hg) (eg github) Clojure lein lein (eg git) (eg git) frank On 20 February 2013 11:20, H. Hirzel <[hidden email]> wrote: > Tobias, > > helpful chart to get the big picture. > Thank you. > > --Hannes > > P.S. How would the Java row look like? :-) > > On 2/20/13, Tobias Pape <[hidden email]> wrote: >> Am 20.02.2013 um 11:30 schrieb Frank Shearar <[hidden email]>: >> >>> 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. >>> […] >> >> Here is my not too serious comparison chart for The Things to Load Code. >> >> Pkg install frontend Package manager Version management Repository >> -------+-----------------------+-----------------------+-----------------------+--------------------- >> Squeak SqueakMap Metacello Monticello SqueakSource/Smalltalkhub >> Python pip eggs ? (eg) hg (eg) bitbucket >> JS npm npm (eg) git (eg) GitHub >> GLASS (Metacello api) Metacello Monticello GitHub/Squeaksource3 >> Debian aptitude dpkg / / >> >> All four categories are necessary and serve very different purposes. >> Note this list is only examples. Note that there may(and should) be certain >> overlaps >> the farther right you get. >> >> Best >> -Tobias >> >> >> > |
Free forum by Nabble | Edit this page |