2009/9/21 keith <[email protected]>: > > On 19 Sep 2009, at 22:06, Stéphane Ducasse wrote: > >>>> >>>> >>>>> goals? >>>> >>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>> recompile) on a set of packages. >>> >>> So, not like Installer that can load packages from everywhere, Gofer >>> will concentrate on MC? What about ScriptLoader? >> >> ScriptLoader will certainly use gofer to install packages instead of >> installer >> > > I always thought that you guys didnt actually understand installer. > Which is partly your own fault. As for the rest of post i agreeing with you. Except, maybe that Gofer may be targeted not only as cross-fork but for cross-dialect tool. But i don't have any info on that, and indeed, i think Installer , with some refactorings could also work as a cross-dialect tool, at least on platforms which already supporting MC.
> Installer is intended to fulfill a strategic role, it has a role > "Installing things", and it is extensible, so that anyone else who > wants to "Install things" can contribute to it and extend it. So when > a user wants to Install things, there is a logical place to go, that > is called "Installer" for installing things. > > If you want to create an additional tool for "installing things" then > why not consider how this tool may provide facilities for installer. > Otherwise this indicates that the whole design concept and envisioned > role of Installer has been overlooked. > > There is nothing wrong with ScriptLoader per se, but to be consistent > with the vision for Installer it would be provided as an extension to > Installer, thus... > > Installer scriptloader doWhateverYouWantHere. > > Installer was created to be the first and only dependency for kernel > images of any kind, that you can use to load additional things. > > You guys come along and use ScriptLoader for roughly this purpose, > thus explicitly ignoring, and implicitly undermining this goal from > the outset. Furthermore none of your scripts in script loader appear > to take advantage of the second installer feature. > > which is... > > Installer is supposed to enable scripts to be written and executed > piecemeal, i.e. bit by bit, in a workspace, or for debugging. i.e. > Installer scripts do not , and should not use temporaries. > > i.e. this style of code is NOT suitable for this purpose. > > | repo | > > repo := Installer squeaksource project: 'This'. > > repo install: 'That'. > > A better code example which has no method temporaries is shown below > > Installer squeaksource project: 'This'; install: 'That'. > Installer monticello http: 'www.myrepo.com'; rememberAs: #mine. > Installer mine project: 'This'; install: 'That'. > > Installer is supposed to provide a uniform API as a front end for all > code loading tools > > so if this new gofer thing comes along, its API (implemented on > InstallerGofer perhaps) could be published as > > Installer gofer project: 'This'; addPackage: 'That'; addPackage: > 'TheOther'; install. > > or > > Installer gofer project: 'This'; addPackage: 'That'; addPackage: > 'TheOther'; merge. > > I think that it would be a shame if the gofer tool whatever it is, > doesn't come with an Installer api, then it would not be contributing > to the Installer story, it would be competing with it, in the same > strategic space. > > Given the fragmentation that is continuing to occur in the speak > community, I think that this is tragic, that we end up with so many re- > inventions of the wheel, yet none of them actually fulfills the role > that, if you sit down and think about it for a few minutes, we > actually need > > I.e. the original invention of Installer was expressly so that EVERY > base image published would at least have Installer loaded (or > loadable) and users could build from there, using whatever tools, and > a consistent API. > Installer helps this along in some situations since it knows how to > load the source from an MC package in the event that MC is not > actually loaded, and this helps with bootstapping Monticello etc. > > If everyone uses, or has the option of using the same tools for > building images, in every release, then this facilitates exchange of > packages among forks, and helps those of us who are not at liberty to > jump ship on a whim, and it helps those who do want to jump ship on a > whim. > > I was asking you for months to think along these lines and make such > strategic choices based upon contributing to things that the squeak > communities have in common or might want to use in common... > > The vision for Installer was to be a base for building derived images > in all release images in all forks. > The vision for MC1.5 was to be a set of tools that actually worked to > load code in all images in all forks. > The vision for LevelPlayingField is to provide bootstrapping for > difficult code to load in all images in all forks. > The vision for Sake/Packages was to be a universal set of package > definitions and dependencies that show what works where in ALL images, > in ALL Forks. > The vision for SUnit-improved was to be a universal means for defining > SUnit and SSpec tests for ALL images so that it is possible to > indicate what works where, in ALL forks, so that packages of tests can > be maintained in common for ALL forks. > > So, may I appeal to you, please contribute to and use installer, > rather than compete with it, and perhaps reconsider your approach to > the other ideas listed above. > > Keith > > p.s. I am considering, recruiting members for an independant "guild" > of package developers, whose role would be to promote interoperability > between squeak forks, so that packages can be developed once and > deployed anywhere. I think this is needed because now we have no core > image developers in either squeak or pharo, that look at > interoperability. > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
