...

Installer cache    install: 'AlgebraicDataType';    install: 'Unification';    install: 'Zippers'

If I rewrite the script thusly:

Installer cache    install: 'AlgebraicDataType'. Installer cache    install: 'Unification'. Installer cache    install: 'UnificationTests'. Installer cache    install: 'Zippers'.

then all goes well.

I noticed the exact same thing just a couple of weeks ago! Just awful.

What you (we!) originally wrote is a natural, user-friendly way to direct the installer, definitely not something that it should silently punish the user for!

But before putting out a reactive-fix, I wanted to see if we could look at the API and understand how Installer is intended to be used. Does one "set up" with builder methods like #addPackage:, and then a pull the trigger with #install to load them all at once?

Or, is it meant to be used like you were -- like a nice utility Facade?

Installer cache install: 'pkg1'; install: 'pkg2'; etc.

Or, something else?

We definitely need to clarify and fix this.

...

and I pass that in as the startup script when I start up my Squeak (whether a pre-4.3 or a 4.3 (yay!)), I see the usual progress bar. It says "Compiling AlgebraicDataType-fbs.nn" and then "Installing AlgebraicDataType-fbs.nn", as expected. And then it says the same thing again, talking about installing and compiling AlgebraicDataType instead of Unification, and then again when loading Zippers.

The packages all load correctly: it's just the progress morph giving a misleading status message. Has anyone else seen this?

Further, the name of the ChangeSet into which the package loads gets mangled to start with the first package loaded. That's because MCPackageLoader>>basicLoad which has:

"Obviously this isn't the package name but we don't have anything else        to use here. ChangeSet current name will generally work since a CS is        usually installed prior to installation."        pkgName := ChangeSet current name.

If I read correctly, Installer eventually calls InstallerMonticello>>basicInstall, which calls "self mcThing load". Had that been "self mcThing loadWithName: <left as exercise to reader>", I think things would be fine, and I'd see sensible changeset names (and status messages during loading). Is it feasible to change Installer to call a better loading method like #loadWithName: ?

frank

Yes, AlgebraicDataType will be installed three times, Unification twice. This is because #install: is implemented as #addPackage:, then #install.

That seems like a very wrong implementation..

Since the Installer subinstance is kept between #install sends, therefore the installations will repeat. The solution is to use #addPackage: and #install directly:

Installer cache        addPackage: 'AlgebraicDataType';        addPackage: 'Unification';        addPackage: 'Zippers';        install

or using a collection:

Installer cache install: #('AlgebraicDataType' 'Unification' 'Zippers')

These solutions would seem to offer a lot less configuratory control -- since nothing could be done between installations. And, even unnecessarily so, since it's really easy for the user to just write #install:. Why have a two-word/two-step API instead of just one that also happens to be a lot more flexible?

I know you were just helping out, it is not your design, but since we all use Installer it's worth to discuss the API in case one of us gets an itch to "fix" it..

Could you be more specific about what you mean by "wrong"?

On Thu, Dec 29, 2011 at 5:21 AM, Bernhard Pieber bernhard@pieber.com wrote:

FWIW, it just occurred to me that the SqueakMap Publishing Guidelines at http://wiki.squeak.org/squeak/6182 seem to use the Installer in this - at least currently - wrong way. Maybe existing scripts are affected?

Cheers, Bernhard

Am 27.12.2011 um 01:16 schrieb Chris Muller:

...

...

Yes, AlgebraicDataType will be installed three times, Unification twice. This is because #install: is implemented as #addPackage:, then #install.

That seems like a very wrong implementation..

...

Since the Installer subinstance is kept between #install sends, therefore the installations will repeat. The solution is to use #addPackage: and #install directly:

Installer cache        addPackage: 'AlgebraicDataType';        addPackage: 'Unification';        addPackage: 'Zippers';        install

or using a collection:

Installer cache install: #('AlgebraicDataType' 'Unification' 'Zippers')

These solutions would seem to offer a lot less configuratory control -- since nothing could be done between installations.  And, even unnecessarily so, since it's really easy for the user to just write #install:.  Why have a two-word/two-step API instead of just one that also happens to be a lot more flexible?

I know you were just helping out, it is not your design, but since we all use Installer it's worth to discuss the API in case one of us gets an itch to "fix" it..