[SciPy-dev] Python (Enthought Edition) for Windows test release

[Joe Cooper]

Prabhu Ramachandran wrote:
> Hi Joe,
> 
> 
>>>>>>"Joe" == Joe Cooper <joe at enthought.com> writes:
> 
> 
>     Joe> Hi all, The much anticipated new release of the Enthought
>     Joe> Edition of Python (a.k.a. Enthon) is just about ready for
>     Joe> release into the real world.  I'd like for some of you brave
>     Joe> developer-type folks to give it a go before I announce it more
>     Joe> widely and link it from the Enthon home page.
> 
> I finally had the chance to install this under WinXP.  The installer
> is excellent!  Many thanks for the effort!  Some comments:

Thanks for giving it a try!

>  1. I suspect you are still using MayaVi-1.3.  This version has a
>     buggy volume module.  The CVS snapshot is available here 
> 
>      http://vvikram.com/~prabhu/download/mayavi/MayaVi-1.3.cvs20040814.zip
> 
>     I recommend using this instead because it supports time series,
>     incorporates serious bug fixes and also supports user
>     module/filter directories.  
> 
>     I'll try and make a 1.4 release sometime soon so this is easier,
>     but if its not a hassle would appreciate if you could use the
>     above snapshot till then.  Thanks!

My policy was to use only the latest release versions of everything, but 
it seems no one does releases anymore, so all the "stable releases" of 
everything are broken in horrible ways, according to the developers. 
;-)  (I grin, but it's proven to be true for just about everything in 
Enthon.  If I don't laugh, I'll cry.)

I've be diverted to working on the Linux version of Enthon for the rest 
of this week, so if 1.4 can happen by Monday or Tuesday, that would make 
me much happier than including yet another snapshot.

>  2. The default heart.mv example that is installed
>     (Enthought/examples/mayavi/examples) has unix style line
>     endings and won't work under win32.  If you convert these to dos
>     style line endings this will work.  All I needed to do was to run
>     lfcr.py on the offending file.  Would be cool if this were done by
>     default.

Hmmm...I didn't have any problems with this file when I was testing. 
But I did re-add lfcr.py and all of the Python tools (or util, or 
whatever it's called, I'm not on a Windows box at the moment) directory 
to the Enthon package with build 1059 or thereabouts.  So I'll take your 
word for it that it is broken and run it through before bundling.

>  3. Seems like the 'enthought' package included is a little dated.  Do
>     you plan to update this to a more recent version?

Yes.  As soon as I get one that builds.  ;-)

>  4. The chm docs are amazing.  However some of the docs like IPython,
>     elmer, SWIG etc. are not part of it.  Would be awesome if these
>     could also be integrated.

Sure would.  I have little clue how to make it happen...but I'll look 
into it.

>  5. The number of useful packages installed is *very* large (you could
>     say "universe included" ;-).  I was actually unaware of all the
>     installed packages -- for example mingw and swig were pleasant
>     surprises.  It would add a nice touch if a small (or not so small
>     :) README.txt with just a listing of all the packages that ship
>     with the installer could be shown after the install so the user is
>     aware of what is installed.

Agreed.  I'll add one to the documentation submenu.

>  6. You seem to have two copies of the VTK Python dlls.  One in
>     site-packages/vtk_python and another in
>     site-packages/vtk_python/vtk.  Plus the vtk*TCL.dll's are also
>     installed.  These are unnecessary and may be removed.  In fact
>     your build script need not build the TCL wrappers at all.  You
>     just need to make sure CMake gets the Tcl/Tk paths so it can build
>     the TkRenderWidget for Python.  No need to turn on Tcl wrapping.
>     You've also turned on building the Patented classes.  This _could_
>     land you in legal trouble.  So, I'd advise that you turn patented
>     libs off.

Hmmm...I inherited the tcl wrappers building stuff.  Will look into 
removing it.

Eric asked for the Patented classes.  I will re-open the issue with him, 
if you think the patents are still in effect, and distributing them will 
cause issues--I don't think there is a problem with us dsitributing 
them, but I would like to warn people off of them, if the patents are 
still in effect.

> Finally, I am interested in learning of your experience with aap.  It
> looks to be a very interesting tool.  I've used scons and scons really
> shines when it comes to building code but I don't think it easily
> allows for the kind of thing that aap is so strong in.  Care to share
> your thoughts and experience with aap?  In particular, do you think it
> is possible to abandon distutils in the future in favor of it?

Given my experience with distutils, I believe it would be possible to 
abandon distutils for a ball of twine and some used chewing gum.  (OK, I 
exaggerate, but distutils strikes me as being incredibly fragile...see 
the thread yesterday on Scipy-users about my troubles building Scipy_core.)

aap is very very good, and Bram Moolenaar has been very responsive to 
bug reports.  It is also pure python, which gives it a leg up for my 
needs, since I can bootstrap up a new Enthon build environment 
(theoretically--this won't become reality until I don't need MSVC6 and 
the Wise install builder...which happens in Python 2.4) with only Python 
2.4 and the free compiler from MS.  And, again theoretically until some 
of the other ugliness has been excised from the system, I can install 
aap and point it to the right place, and have it download all of the 
packages, build them, and bundle them up, without any human 
intervention.  New versions will be a lot easier.

But for a general build/install utility, I have little experience with 
it.  I certainly wouldn't argue against it, as it simply has to be 
better than distutils.  It's only negative is that it is a new thing for 
folks to learn.  It took me an afternoon to get the gist of it, and I've 
never bothered to get much beyond that--though I will spend more time 
with it once I'm working on 2.4 and all of the uglies in the 2.3 build 
are just a bad memory.

> Anyway thanks again to you and Enthought for the enormous effort
> involved in this task and for the quality of the packaging!

Thanks for the kind words.  And thanks again for looking at it.  Because 
I have so little knowledge of most of the components (there's just too 
many to keep up with, and a lot of it is far outside my area of 
expertise), I really need input on how stuff works.  If I don't hear 
complaints or comments, I assume everything is perfect, and I work on 
other things.