Monticello: loading multiple packages only mentions first package's name

I have a small Installer script called logic.st:

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

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?

frank

On 26 December 2011 20:44, Frank Shearar <[hidden email]> wrote:
> I have a small Installer script called logic.st:
>
> 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.

> 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

On Mon, 26 Dec 2011, Frank Shearar wrote:

Yes, AlgebraicDataType will be installed three times, Unification twice.
This is because #install: is implemented as #addPackage:, then #install.
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')


Levente

>
> frank
>
>

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.

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

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

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:

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


On Thu, Dec 29, 2011 at 5:21 AM, Bernhard Pieber <[hidden email]> wrote: