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

[Joe Cooper]

Prabhu Ramachandran wrote:
>>>>>>"JC" == Joe Cooper <joe at enthought.com> writes:
> 
> 
>     JC> Prabhu Ramachandran wrote:
>     >> 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!
> 
>     JC> My policy was to use only the latest release versions of
>     JC> everything, but it seems no one does releases anymore, so all
>     JC> the "stable releases" of everything are broken in horrible
>     JC> ways, according to the developers.
>     JC> ;-) (I grin, but it's proven to be true for just about
>     JC> ;everything in
>     JC> Enthon.  If I don't laugh, I'll cry.)
> 
> Well, in my case the CVS snapshots are actually stable. ;-) I have had
> several problems making a release.  The biggest being lack of easy
> availability of a win32 box to build the win32 binary.  Starting this
> week I have easy access to a win32 box, so this is not an issue
> anymore.

Understandable.  The reason for not using CVS snaps is not entirely 
stability.  It is the "known quantity" state of releases.  It makes it 
easier to deal with bug reports to have a known version--and one that 
others or I can compare the Enthon build against.

Because there can be problems with either my build or the software 
itself, and I'm going to hear about both, it's nice for me to be able to 
say "Do you have the same problem with a non-Enthon build of the same 
version of the software?"  And though they may not have an answer or be 
capable of testing, at least there's somewhere to start.  Snapshots are 
much harder if I want to do this, because I have to make the snapshot 
available somewhere, for later comparison sake.

Bug fixes upstream are easier to keep up with for versioned software.

Bug reports upstream are easier to make for versioned software.  (Rather 
than saying "I checked out from CVS...ummm, a couple of weeks ago...maybe?")

Versioned software is easier to sync up across multiple platforms.  I am 
building for multiple Linux distros and Windows.  If I know the version, 
and it is a release version, I can pull it from the origin with my build 
scripts without having to keep a synced up repository of my own pristine 
sources that all platforms can access.  I'd like for all of the 
platforms to be using the same version--and Robert Kern has expressed an 
interest attempting to roughly mimic that policy for Mac Enthon.  The 
goal, of course, is for someone to be able to work on their Mac laptop 
on the road, their Linux desktop at home, and their Windows desktop at 
work, without having to think differently for each platform...to as 
great a degree as is possible given the current state of the tools on 
each platform (for an example of a limitation to this plan, wx 2.4 is 
not supported on Mac OSX, but it is the version we continue to 
distribute for Windows and Linux and will for the foreseeable 
future--Dave adamantly refuses to work with APIs that change frequently, 
and until there is an official 2.5 release, I agree whole-heartedly with 
him).

>     JC> I've be diverted to working on the Linux version of Enthon for
>     JC> the rest of this week, so if 1.4 can happen by Monday or
>     JC> Tuesday, that would make me much happier than including yet
>     JC> another snapshot.
> 
> OK, I'll push its priority up and try to get a 1.4 release done ASAP.

I do appreciate it.  Don't work yourself too hard to do it...My ideal 
world won't be happening with this release, regardless of whether your 
release occurs.  But I'm trying to establish some guidelines that make 
it easy for developers to get their software into Enthon in a form that 
works well, making both me and the developer look good to the end user.  ;-)

By the time of the 2.4 release, I will likely be much more stringent 
about including release-only versions of software.  Since that is a 
couple of months away to coincide with the next versioned release of 
SciPy, it gives everyone a little while to make up their mind about 
inclusion in Enthon and how much it means to them.  I have an inkling of 
an idea for making it possible for developers to make easily installable 
sub-packages available for Enthon, without having to make it in on my 
release schedule...we'll see how that turns out.  It might even mean the 
main Enthon download can shrink in the next release.  ;-)

>     >> 3. Seems like the 'enthought' package included is a little
>     >>    dated.  Do
>     >> you plan to update this to a more recent version?
> 
>     JC> 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.
> 
>     JC> Sure would.  I have little clue how to make it happen...but
>     JC> I'll look into it.
> 
> Hmm, well you (or some magical elf on your machine ;-) seems to have
> done it for the MayaVi documentation -- its part of the big Enthought
> Python chm.  So I guess the same magic would do for these.

Yes.  I believe everyone here likes to think of Dave Morrill as our 
resident magical elf.  But he no longer waves his wand over Enthon, so 
we're stuck with what I can manage.

That said, by my understanding the process that Dave used to generate 
the .chm was neither magical nor vaguely automatic.  So it has taken a 
back-seat to getting a package that works.  I have focused a bit on 
getting better access to documentation into the menu, though, and I will 
see if I can work towards automating the process of importing the 
existing HTML/LaTeX/Docbook/man/whatever documentation into the .chm.

>     >> 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.
> 
>     JC> Eric asked for the Patented classes.  I will re-open the issue
>     JC> with him, if you think the patents are still in effect, and
>     JC> distributing them will cause issues--I don't think there is a
>     JC> problem with us dsitributing them, but I would like to warn
>     JC> people off of them, if the patents are still in effect.
> 
> IIRC, Robert Kern raised very valid concerns about this on the
> MacEnthon thread on this list.  I am totally clueless as to the nature
> of the patents and when they expire.  I just thought I'd mention it so
> you are aware of potential problems.

Yeah...My position was "I will not include the patented classes, until 
those patents are confirmed expired".  Eric vetoed that position on the 
basis that he thinks one of the patented classes is pretty cool.  I 
think there was some debate on whether some or all of the patents were 
still enforceable.  I suppose we'll have to see.

Anyway, my understanding is that free distribution is never a problem. 
So our primary responsibility is to warn people of their existence 
within the distribution, so they won't use them in commercial software 
without awareness of their liability...since they have to read the VTK 
docs to use them, I would guess that would know which classes were 
questionable.  But I'll add a "README.PATENTED" to the docs directory 
and docs menu to explain it all.

Thanks again for the feedback.

And don't forget (like I did for the first several months after I took 
over the project) that there is an issue tracker just for Enthon:

https://www.enthought.com/roundup/enthon

Wishes and bugs reported here are more likely to be acted upon than any 
others.  Not because I don't want to do everything everybody mentions on 
the mailing list, it's just impossible to keep up with all of it.