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. 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.