[IPython-user] Got bdist_wininst working for IPython ...
viktor.ransmayr at t-online.de
Tue Jan 11 16:04:19 CST 2005
> Hi Fernando,
> You wrote:
>> Viktor Ransmayr wrote:
>>> No problem. I'm happy if I can contribute. - Now about this next
>>> I don't know how much time you spent looking at my modifications yet.
>>> However I still have a few questions about the further proceeding:
>>> 1) There is no need to install pywin32 for the installation process
>>> on window.
>>> - At least not for bdist_wininst. - Should anything be checked
>>> during the
>>> import or do you think a simple message, stating that pywin32,
>>> and readline are recommended is sufficient ?
>> I'd say printing a user message would be a very good idea. ipython
>> will _work_ without this stuff, but it will lack some of its nicest
>> functionality (readline and coloring). So a prominent message in
>> this direction would certainly help. A simple
>> import ctypes
>> except ImportError:
>> print 'get ctypes from http://....'
>> and similar for readline would be very good to have. No need to
>> bother users who already have them with this, though.
> OK. - I'll add such a check to my next version of the vr_* version of
> the scripts.
>>> 2) I'm not sure what should be done in the case of cmd=bdist ? -
>>> What I did
>>> not like about the way "IPython-0.6.6.zip" worked, was the fact
>>> that it did
>>> install files outside of ..\Lib\site-packages\IPython\ without
>>> giving me any
>>> means to deinstall. (Other than saving the complete output of
>>> the install-
>>> cmd into a log-file and removing everything by hand :-)
>>> Do you have an idea/ a plan or do you think that simply removing
>>> usage of the post-installation script completely from the
>>> zip-archive is
>>> sufficient and/or acceptable ?
>> Mmh, I think I'm a bit confused here. I guess our ultimate goal is
>> the following:
>> 1. An ipython_setup.exe real windows installer is available, which
>> can both install AND uninstall ipython by the usual windows
>> mechanisms, leaving no junk behind it after uninstallation.
>> 2. The ability for windows users, if necessary, to run by hand in a
>> terminal 'python setup.py install' and have the thing work as well.
>> I think it's acceptable in this scenario to lose uninstallation
>> capabilities, since they don't really exist with a manual install
>> under unix either. Under unix, if you want uninstall capabilities,
>> you need to use a package manager (rpm, apt, fink), so the same
>> applies for windows (the .exe installer playing the role of a package
>> My understanding is that we already have #1 with your work. It's
>> just a matter of keeping #2 as an option, for those who download the
>> sources. I'm even willing to stop distributing .zips once the .exe
>> installer becomes available: a source install for windows users will
>> be at that point a much more rare occurrence, and I expect it to be
>> done only by very technically minded users. Since winzip can handle
>> .tar.gz files just fine, they can always grab that.
>> This means that it's OK to remove the hacks I had to inject an
>> 'install' command into sys.argv in setup.py for windows users. The
>> question I have is, what does setup.py see when it is called by the
>> .exe installer? What does sys.argv look like in that scenario? We
>> basically need some way of distinguishing if it's being called by the
>> .exe installer, who will in turn execute the post_install script
>> itself, or by a user at a command line, case in which we need to run
>> it ourselves. Is this possible?
> I'll work on that question tonight. - I'll keep you informed.
Two initial statements:
o At this point in time I can still only provide my understanding of the
w/o having verified this with _another running_ prototype (yet).
o Re-Reading this mail-thread I also get the feeling that I have
"misslead" you with some
of the terminolgy and cmd-usages I've mentioned, quite a bit as well :-(
However here's my current summary and initial answer :-)
1) Distribution time vs. Installation time
1.1) At distribution time the _developer_ can create a
1.1.1) module/ extension either as a
- source-distribution (via sdist-cmd)
OR as a
- binary-distribution (via bdist*-cmd)
18.104.22.168) He/ She can create such a distribution either
- implicitely ( w/o specifiying the format-parameter)
- explicitely ( w/ specifiying the format-parameter )
1.2) At installation time the _user_ can execute a
1.2.1) module/ extension created w/ a source-distribution
- via the install-cmd
OR can execute a
1.2.2) module/ extension created w/ a binary-distribution
- via "installing" the distributed EXE
- via "installing" the distributed RPM
This is a very long intro to simply say, that I think your current use
(as of 0.6.6)
of the post_install-script, directly inside the setup-script, has not
by the distutils-developers.
However I'll verify this (current personal) view on the distutils
More information about the IPython-user