By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,211 Members | 1,052 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,211 IT Pros & Developers. It's quick & easy.

distutils, 'scripts' and Windows

P: n/a
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=<myinstallscript>
which ought to do the trick. But to use this, myinstallscript itself
must first be installed by passing
scripts='myinstallscript'
to distutils.core.setup in setup.py. That will copy myinstallscript
into a particular location (C:\Python24\Scripts 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

Jul 19 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
"George van den Driessche" <gr***@bigfoot.com> wrote in message
news:d7*******************@news.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=<myinstallscript>
which ought to do the trick. But to use this, myinstallscript itself must
first be installed by passing
scripts='myinstallscript'
to distutils.core.setup in setup.py. That will copy myinstallscript into a
particular location (C:\Python24\Scripts 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


Jul 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.