Hi again!

Bernhard Pieber <bernhard at pieber.com> wrote:
> Thanks for quick your answer, Goran! See my comments below.
> 
> goran.krampe at bluefish.se wrote:
> > > Note that I am aware that installPackageNamed: should not be used any
> > > more. Is there a protocol which does exactly the same as the Package
> > > Loader if I click yes twice? The methods
> > > #installPackageLatestPublishedNamed: and
> > > #installPackageNamed:autoVersion: seem to do slightly different things.
> > 
> > "Yes twice" ought to mean that you want to install the latest release
> > regardless of the current image version or if it is not published. That
> > is not advisable to have in a load script since it will disable both
> > those mechanisms and cause unexpected problems for the user.
> What I want to live wild and dangerous? ;-)

I assume you meant "What if I...". Well, the problem is that if you are
writing such a load script - you are deciding that *others* want to live
wild and dangerous. That doesn't seem fair! :)

What we could do is to add support to SMSqueakMap so that you can easily
get the exact same behaviour as in the loader - with questions and all.
Instead of exceptions. Then the user will be aware of stuff getting
installed which may be "shaky".

> > Note that I am aware that there are quite a few methods for installation
> > now and some overlap etc, I need to make this clearer. Anyway, my advice
> > is to either specify a specific release like this:
> > 
> > SMSqueakMap default installPackageNamed: 'Worlds Of Squeak Removal'
> > autoVersion: '1'
> That is what I use currently.
> 
> (Just fyi, it took me several tries until I figured out what was meant
> with autoVersion. First, I tried '2', then 2, then 'r1'. Then I almost
> concluded the method was broken. Only then I had the idea to try out
> '1'.)

Ah. Yes... I have written it like "rX" in order to find a clear syntax
that people can use which is recognizable as an automatic version. But
docs are lacking of course, should write an article at least.
 
> > Since we are pointing at a specific release this will "bypass" the
> > checks if it is in fact published/not published or marked for the Squeak
> > version that the user has.
> > 
> > The other method you mention, #installPackageLatestPublishedNamed: and
> > it's sister method #installPackageLatestPublished: should IMHO probably
> > be removed. They don't check the Squeak version and probably only
> > confuse things.
> > 
> > Ok, if you don't want to specify a specific release - then the
> > installPackageNamed: would work *iff* there was a published release of
> > "Worlds Of Squeak Removal" that also was marked for Squeak 3.7.
> Well, this illustrates the problem with approaches like this: When a new
> release is made all packages are automatically shown as "dangerous" to
> the user even if they work fine. In a way, you get hundreds of false
> positives and need manual intervention of a developer to remove them
> again. And this even for ultra stable packages which were not touched
> since a long time.

Yes, but be aware "ultra stable packages" can break just as easily. For
example, we recently changed the behaviour of new/initialize. :) The
Atomic game broke because of that - and it sure hadn't been touched at
all.

So I still think it is the right way. As long as you as a user can have
the choice and be aware that - "oh, the maintainer hasn't tested this in
3.7, ok, I will try it anyway...".

> That leads me to the following conclusions: If a package is not marked
> as 3.7 chances are high that it works anyway. OTOH, even if a package is
> marked as 3.7 it does not guarantee that it will work, because chances
> are high that there are conflicts with other packages marked as 3.7.
> Therefore I pretty much ignore this category completely.

Well, you are free to do that. :)

> Thinking about it, I'd find it interesting to try out the opposite
> approach: to list only information of the following kind: Package A
> Version 1 is known to have a conflict with Package B Version 3. I can
> imagine that this would be much less information and thus much easier to
> maintain. It would be necessary that this information can be supplied by
> anyone, not only the package developers.

This is lined up in my plan for dependencies.

> > So given the two "safety mechanisms" we have now - the check for
> > published, and the check for correct Squeak version - the
> > install-methods that do not specify a specific release are much more
> > "ok" to use.
> With all respect, I disagree. To load the latest version of a package
> regardless of the Squeak version I use seems a very common use case to
> me. I would even dare to bet that most people will answer yes to both
> questions in almost all cases.

I am not sure you understood what I wrote. :) Earlier I have advocated
against *not* specifying a specific release in load scripts. Now i am
saying that given this "smarter" mechanism - it might be ok not to do
that. Because it will try to select the latest published that is know to
work with your Squeak.

And again - do note that if you want to be on the edge - just select the
latest *release* (instead of just the package) and select "install".
Should work.

> Thanks again for looking into my problems and for your valuable
> contributions to Squeak! SqueakMap is really great!
> 
> Bernhard

Thanks!

regards, Göran

PS. The mechanisms we have today are "band aids" in some ways. We need
to remember that.