[SciPy-dev] ipython in enthon

Fernando Perez Fernando.Perez at colorado.edu
Thu Nov 11 01:20:35 EST 2004


Hi Joe,

Joe Cooper wrote:

> I'm down to iPython now as the last remaining piece of the puzzle before 
> I roll up a new test installer of Enthon.
> 
> Here's the problems I've run into:
> 
> setup.py doesn't respect prefix (at least on Windows--I haven't built an 
> RPM on Linux yet to find out how it behaves elsewhere), so it dumps 
> everything into my system default Python.  Not ideal for packaging.

Yup, and here's why:

# Under Windows, 'sdist' is not supported, since it requires lyxport (and
# hence lyx,perl,latex,pdflatex,latex2html,sh,...)
if os_name == 'windows':
     setup = os.path.join(os.getcwd(),'setup.py')
     if len(sys.argv)==1 or \
            sys.argv[1] not in ['install','bdist','bdist_wininst']:
         sys.argv = [setup,'install']

It's a horrible hack I put in to bluntly override everything, since I never 
thought anybody could actually try to build a package on a windows box.  The 
problem is the document generation, which requires a pretty hefty bag of tools 
(latex, latex2html, perl, lyx and lyxport 
[http://www-hep.colorado.edu/~fperez/lyxport]).  You could try to comment this 
out, but I don't know if you have all these tools on your windows box.

A potentially cleaner approach might be to generate the windows installer 
under linux, which is what I was trying to do originally.  There, you have 
most of the necessary tools already, and the only ones you might not have, lyx 
and lyxport, are trivial to add.  You could also start from a source download, 
which already includes all the built manuals in PDF and HTML, hence saving the 
need for the build toolchain.


> The pythonwin stuff needs to be able to be disabled from the command 
> line.  It installs a bunch of bits on the local machine, which is 
> destructive to the build environment.  We can setup the shortcuts and 
> such in the enthon installation routines.

This is at the end:

# For Unix users, things end here.
# Under Windows, do some extra stuff.
if os_name=='windows' and 'install' in sys.argv:
     import ipython_win_post_install
     ipython_win_post_install.run(wait=1)

For a normal 'install' call, the post_install script gets run.  But if you 
disable the auto-install stuff I put in (mentioned above), you'll have control 
over how this gets called.

> It hangs at the build phase, for some unknown reason, seemingly at or 
> near the end, because lots of stuff does actually get built.  I'll have 
> to dig a bit to see what's happening there.  It could be related to the 
> win32all installation, as it's installer freaked out in a weird way as 
> well, and refused to overwrite a file because python was running 
> (clearly--python was doing the install!).

Yes, I remember seeing that strange hang the last time I tried to get this to 
work under windows.  That's when I gave up and put in the primitive zip-based 
installer, with the manual hack you see above.  That hack basically ensures 
that people can double-click on the setup.py file and it ...

[your other message just came through, it seems you got it.  I'll still send 
this for reference.]

Best,

f




More information about the SciPy-Dev mailing list