distutils/package installers on windows

Bengt Richter bokr at oz.net
Tue Feb 19 18:22:23 EST 2002


On Tue, 19 Feb 2002 20:01:04 +0100, "Thomas Heller" <theller at python.net> wrote:

>
>"Bengt Richter" <bokr at oz.net> wrote in message news:a4smoa$h20$0 at 216.39.172.122...
>> >The source code IS available:
>> >http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/distutils/
>> >in the misc directory. Guess I'll have to add a note about this
>> >to the source... There is a tricky symbolic link somewhere on SF
>> >which links parts of the distutils tree into the Python source tree.
>>
>> That self-update of the bin64 EXEDATA string seems a little tricky too ;-)
>> I guess I would rename the old version to a backup name before writing
>> the new, not being aware of the larger context. Or should one
>> copy it to ../otherdir and run ../otherdir/it that way? Or did I read
>> too fast?
>
>CVS gives enough backup for me, and it has worked for me so far.
>
I'd have guessed so for you, and, ok, I guess anyone having a seriously modified
version would not run it without knowing what it was going to do first ;-))
>>
>> >
>> >> Having some additional hooks created in distutils to execute
>> >> post-installation sounds like it could be a useful enhancement.  At
>> >> least with that sort of scenario you could write your own shortcut
>> >> creating code without modifying the core distutils itself.
>> >
>> >I'm currently working on an bdist_wininst enhancement which
>> >takes an additional command line option (--install-script <script.py>).
>> >This script would then be run (with sys.argv set to [script_name, '--installed'])
>> >after all the files have been copied, and it would again be run
>> >(with sys.argv set to [script_name, '--removed']) just before
>> >the deinstaller is about to remove all the files and directories.
>> >
>> Sounds good. I wonder if something is needed to cater to version upgrading
>> and/or multiple version installation. E.g., to give an old version a
>> chance to have a script automatically executed '--before_upgrade' and
>> '--after_upgrade'? Can the binary installer run something before even
>> copying any new files? I.e., the old version interpreter and its
>> 'im_about_to_have_a_sibling.py' script? Putting it in the installer
>> sequence would protect against user forgetfulness (otherwise s/he could
>> obviously do it manually), and an old version could at a minimum output
>> some attention-grabbing reminders from the authors of the old version.
>
>Well, I want to keep the C-coded part as simple as possible.
>On the other hand, you could play any tricks you want in
>the installation script. Detect upgrade yourself!
>
That would work if there were a reliable convention of loading the new files
completely separately (e.g., no replacing anything in %SystemRoot%\system32)
and also a convention for finding elements of the old version -- in particular,
a place for a pre-upgrade script. The new install script could then
execute the pre-upgrade script and the old version could have its say
about being replaced.

Note that the pre-upgrade file could be modified incrementally (by hand
or potentially sometimes automatically) when special packages were
installed, so the upgrader could be reminded to check whether s/he has
e.g. a new version of PIL or such to go with the new interpreter.

Without complete version storage separation, at the opportunity point
(*after* copying files) you propose, it may be too late to warn
not to copy over something. I hate installation programs that arrogantly
proceed to replace things without warning, but many do. Not to mention
grabbing extension and file type associations and tool bar menus. Grr...

Regards,
Bengt Richter





More information about the Python-list mailing list