distutils, 'scripts' and Windows

[George van den Driessche]

Hi folks,

I'm looking at packaging a project I'm working on using distutils. The
project is for Windows and contains a COM server which needs
registration, so the installer needs to be a little more complicated
than usual. Looking at the options for the bdist_wininst command to
distutils, I see it's possible to specify
--install-script=<myinsta llscript>
which ought to do the trick. But to use this, myinstallscript itself
must first be installed by passing
scripts='myinst allscript'
to distutils.core. setup in setup.py. That will copy myinstallscript
into a particular location (C:\Python24\Sc ripts in my case) and leave
it there forever. Which raises a couple of questions:

- Why is myinstallscript left there forever? The documentation makes
some vague reference to needing it for uninstalling packages, but then
I can't actually find a way to uninstall packages.

- What is the use of the Scripts directory on Windows? It's not added
to my PATH, so unless I do that myself it won't do anything like it's
meant to on other platforms.

- Should I supply myinstallscript , or myinstallscript .py? I suspect the
latter, since that's the only way to give files types on Windows.

- Is there some other better way to perform post-installation actions?
Would it work out of a binary generated from bdist_wininst?

- Should I even be using distutils? It doesn't really matter that much
where the files are installed because the COM server can register
itself to run out of whatever location it happens to be in.

Thanks,
George

[John Roth]

"George van den Driessche" <gr***@bigfoot. com> wrote in message
news:d7******** ***********@new s.demon.co.uk.. .

Hi folks,

I'm looking at packaging a project I'm working on using distutils. The
project is for Windows and contains a COM server which needs registration,
so the installer needs to be a little more complicated than usual. Looking
at the options for the bdist_wininst command to distutils, I see it's
possible to specify
--install-script=<myinsta llscript>
which ought to do the trick. But to use this, myinstallscript itself must
first be installed by passing
scripts='myinst allscript'
to distutils.core. setup in setup.py. That will copy myinstallscript into a
particular location (C:\Python24\Sc ripts in my case) and leave it there
forever. Which raises a couple of questions:

- Why is myinstallscript left there forever? The documentation makes some
vague reference to needing it for uninstalling packages, but then I can't
actually find a way to uninstall packages.

- What is the use of the Scripts directory on Windows? It's not added to
my PATH, so unless I do that myself it won't do anything like it's meant
to on other platforms.

- Should I supply myinstallscript , or myinstallscript .py? I suspect the
latter, since that's the only way to give files types on Windows.

- Is there some other better way to perform post-installation actions?
Would it work out of a binary generated from bdist_wininst?
What I found, thanks to Martin Fuzzey, is that if you assign the result
of the setup() function to a variable, you can access all sorts of
interesting stuff after setup() completes. You need to do some
source reading, but it's quite instructive.

Also, if you check the parms after setup completes for "install" or
whatever other subcommand you're using to install the stuff, you
can then do pretty much whatever you want without having to
have another script. I convert line endings on all of my scripts
manually since distutils doesn't seem to do it. I should also
convert line endings on the documentation. Sigh.
- Should I even be using distutils? It doesn't really matter that much
where the files are installed because the COM server can register itself
to run out of whatever location it happens to be in.
I personally find distutils to be an absurd fit for my application
(PyFit). It does way more than I need, and doesn't do a lot of
other stuff that I need, and makes lots of assumptions about file
locations that are simply, um, well ...

Unfortunately, it's also the standard installation engine, so there's
no getting around it if you want to be consistent with what everyone
else is doing and future enhancements to the installation process
through the Python Package Index, eggs and a lot of other
stuff that's coming down the pike.

John Roth

Thanks,
George