[SciPy-dev] ipython in enthon
Fernando.Perez at colorado.edu
Thu Nov 11 00:20:35 CST 2004
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 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:
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.]
More information about the Scipy-dev