Automatically unloading a package when loading another package

Hi,

I'm trying to automatically unload a package when loading a new
package.

The problem is that the package to be unloaded contains the same
classes as the new package, the whole reason why I want to unload the
old package first. Now it appears that the preinstall code saved in a
package only gets evaluated after a sanity check is made for loading
the new package. In my case this brings up the error message that the
classes in the new package already exist, exactly what I'm trying to
avoid with the preinstall script.

Anybody any idea?

Thanks,

Ted

btw this is the preinstall code

| package |
package := PackageManager current packageNamed: 'Package1' ifNone: [].
package isNil ifFalse: [PackageManager current removePackage:
package].

Ted,

>               Now it appears that the preinstall code saved in a
> package only gets evaluated after a sanity check is made for loading
> the new package.

It's a pain isn't it. I did once wonder about asking OA for a pre-preinstall
script that was always evaluated before any other checks were made. It
seemed a bit of an ugly solution though and I wasn't sure it would work with
the automatic loading of prerequisite packages.

> Anybody any idea?

I've never found anything that worked particularly well. The choices seem to
be

1) Modify the image to allow overwrites - there are a number of places his
can be done with varying degrees of disruption and danger.

2) Remove the existing package by evaluating code externally, either in a
file-in script (.st) file or as a script in a dummy package, that you load
instead of the "proper" package.

3) In certain circumstances it is possible to save the classes in .cls
files, all loaded by a single .st file script, and not bother with a package
at all.

All these can be made to work but I found that they could easily make things
more complicated (and error prone) than just uninstalling the package (or
individual classes) manually.

I know that Chris Uppal did a lot of work on packages and making them safer
to use, perhaps he came up with something?

Regards
    Ian

Ted,

> I'm trying to automatically unload a package when loading a new
> package.

What are you really trying to achieve ?

As Ian has said, I have spent some time (in fact *far* too much time)
building tooling to try to make it easier/safer to work with packages;
unfortunately I don't have anything to add to the suggestions that Ian's
already made.  At least not on the basis of what you ask in your post.

> Ted

    -- chris

Ted,

> > I'm trying to automatically unload a package when loading a new
> > package.
>
> What are you really trying to achieve ?
>
> As Ian has said, I have spent some time (in fact *far* too much time)
> building tooling to try to make it easier/safer to work with packages;
> unfortunately I don't have anything to add to the suggestions that Ian's
> already made.  At least not on the basis of what you ask in your post.

I've always been a little conservative (ok, just plain chicken hearted<g>)
when it comes to packages.  My current image has 111 packages installed at
present, so I definitely want some help in getting them loaded into a new
image; Migrate does that for me.

If I wanted to exchange one package for another, I would at least consider
having Migrate write a list of packages to be loaded, edit it to replace the
current package with the new one, and build a new image.  That would
probably require making an empty package with the removed package's name
just long enough to make the dependent packages happy; once they are
re-saved, they'll figure out that they don't need the removed package.  I'm
assuming the prerequesites will otherwise be the same, though with
improvements in Dolphin over the past couple of years, that might not matter
as much as it once did.  I'm further assuming that lots of other package
depend on it, otherwise, I'd just uninstall it manually.

The other conservative<g> thing that I do is build the next generation of
any important subsystem with a slightly different name.  Most of the time, I
find that the names were a little off anyway, and even if they are not, it's
just a heck of a lot more convenient to build and test knowing that I can
use the same image to deploy hot fixes until I'm really ready to make the
switch.  By that time, it's usually very quick to make the change to the new
version, after which the old package can be uninstalled.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Hi Ian, Chris and Bill,

With my book the reader receives a CD with a package per chapter.
Initially I made those packages incremental; leave chapter 3 package
in the image and load chapter 4 package. Unfortunately I got stuck
with that approach at some point because I inserted abstract classes,
removed globals and things like that, so I had to create a package per
chapter which also contained the classes of the previous chapters.
Hence the need to uninstall the previous chapter's package before
installing the current. I was hoping to keep it simple ;-) I think I
just stick to describing that the previous chapter has to be
uninstalled before installing the next chapter. Dolphin comes back
with an error if you don't anyway.

Thanks for the suggestions.

Ted

Ted

> I think I
> just stick to describing that the previous chapter has to be
> uninstalled before installing the next chapter.

Sounds like the right approach to me -- in this context "clever" tricks
would definitely be counter-productive.

BTW I'm looking forward to seeing the book.  I've had it on order since the
begining of the year.

> Ted

    -- chris

Hi Chris,

"Chris Uppal" <[hidden email]> wrote in message news:<[hidden email]>...
Thanks for the confidence, that's one book sold ;-)

Ted

Ted Bracht wrote:
Implement reloading such that when loading a package that is already
loaded the loader compares the new and existing code, loads the delta
and then runs the post-load action.  We implemented this in VisualWorks
5i.3 and have most of the bugs out in 5i.4.

It seems to me this is the only dynamic approach that scales:

- if you have a lot of packages that depend on the package you want to
reload they you have to unload them before you can reload.

- if you have lots of existing instances of classes in the package
you'll either have to just throw them away, or make them persist in
binary storage and reload them after the reload.

Of course you could take a static approach.  Then you never have to
reload; instead you rebuild a new system.  But that only works for
certain applications; 24x7 applications have to have some way of
evolving.

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd