[SciPy-dev] Python (Enthought Edition) for Windows test release
joe at enthought.com
Fri Jan 28 14:18:03 CST 2005
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
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
> 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:
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.
More information about the Scipy-dev