distutils/package installers on windows

Bengt Richter bokr at oz.net
Tue Feb 19 00:10:34 EST 2002


On Mon, 18 Feb 2002 22:38:46 +0100, "Thomas Heller" <theller at python.net> wrote:

>
>"David Bolen" <db3l at fitlinxx.com> wrote in message news:u4rkezl0l.fsf at ctwd0143.fitlinxx.com...
>> The binary portion of the windows specific installer is hardcoded into
>> the distutils package (encoded in the bdist_wininst.py module), and it
>> doesn't appear that source is available (at least I can't seem to find
>> it even in the CVS tree) so changing how it behaves doesn't seem easy.
>> You could replace it outright, but then you'd have to duplicate its
>> existing functionality as well.
>
>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?

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

Just a couple .01USD

Regards,
Bengt Richter




More information about the Python-list mailing list