Kevin Ollivier wrote:
Hi Robin,
Hi all,
I've now included an uninstaller script with the OSX builds of wxPython that will help manage the versions that are installed. Since the new packages have a new name they will not automatically upgrade 2.5.2.8 or prior versions so I reccommend using the uninstaller first. It's a text mode tool so it can be run from the commnad line or opened with PythonLauncher which should launch a terminal for it to run in. Let me know if there are any problems with using it.
I've just tested the new installer (though I forgot to run the uninstaller and am not sure if I should do it now... ;-/ ).
It should still work fine, I did that once too and so it's been tested once. Give it a try and let me know if there are problems.
Everything seems to work ok, but I really don't like this idea of installing the "common" parts separately. It's all too easy to just forget to run the common installer and end up installing new wxPython libraries which end up not even being used. Furthermore, the mistake won't be obvious or quickly noticed, so it won't be easy for people to figure out they're running the wrong version.
I can't really think of any use case in which the latest version *shouldn't* be the default, except for test releases, which IMHO should be handled separately. (Really, if we're devising a solution for that, people want to be able to turn test releases "on" and "off" depending on what they're doing.) Well, anyways, I've covered this in previous emails so I probably shouldn't repeat myself.
Anyways, long story short, I can't see any reason why the common bits should be a separate install, and it's likely to lead to people making mistakes during installation.
It was more of a better safe than sorry decision than anything else since I don't know if there are any negative implications to having overlapping files between different Apple Installer packages. I did some reading and couldn't find anything about it one way or the other.
I can combine them back fairly easily, but I'll also have to make some tweaks to the uninstaller script to leave those files alone if there are more than one wxPython installed.
Another option is to make it into a metapackage installer, then the common files can optionally be turned off like in the Windows installer. (The Options button on the last screen before the instal is started will become active and you can then check/uncheck the subpacakges.) But to do that I'll need to update the buildpkg.py tool to use the newer plist structure for the package data and also to support building metspacakges, and that is an added complexity I don't have time to tackle just yet.
I'll try to squeeze in the combining of the pacakges before starting another daily build tonight so we can test and see if there are any problems.
···
On Oct 22, 2004, at 8:12 AM, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!