Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > RE: Python evolution: Unease

Reply
Thread Tools

RE: Python evolution: Unease

 
 
Scott David Daniels
Guest
Posts: n/a
 
      01-07-2005
Terry Reedy wrote:
> Even though I currently only have 80 ... I realize that my stinginess
> with disk space for more serious stuff is obsolete. A gigabyte would
> cover Python + Wxpython + numarray + scipy + pygame + a lot
> of other stuff.
>
> Would it be possible, at least for Windows, to write a Python script
> implementing a 'virtual distribution'?
> IE, download Python, install it, download next package, install it,
> etc. -- prefereably table driven?


I would suggest looking to the Enthought distribution as a reasonable
base (gets you an awful lot). Enthought has a _large_ collection,
covering a lot of stuff that has general utility. Their production
stuff is still at Python 2.3.3, but I believe they have a 2.4 version
coming soon. The list of what they put in the 2.3.3 package is truly
impressive:

wxPython, PIL, VTK, MayaVi, Numeric, SciPy, ScientificPython,
F2PY, Chaco, Traits, PyCrust, ZODB, Gadfly, PySQLite, and ctypes.

All for one sub-90-Meg download. I add VPython to get dirt-simple 3-D
stuff; you'd probably add pygame. The key to this is Enthought's
attention to testing a stable "sumo" collection. I add a few packages
that are much more anachronistic. My thought basically is that, since
I want at least four of the packages, getting a "blessed" superset eases
my installation woes.

If you can wait, the plan for MacEnthon (Python 2.4 on Mac) looks great:

http://www.scipy.org/wikis/featurerequests/MacEnthon

I seem to remember discussion about synchronizing with the windows 2.4
version to have essentially the same list.

--Scott David Daniels
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Nick Coghlan
Guest
Posts: n/a
 
      01-07-2005
Bulba! wrote:
> When you have it ALL in the single distro, released from time
> to time, you can easily test it _together_. You don't
> get _temporal dependencies between various versions_.
> The released, stable distro has the same things on the
> same days, and either it all works together or it doesn't.


Except that the difference between the distro maintainers' opinion of what is
"stable enough" for inclusion, and the updated version of that module which has
some stability problems in areas you don't use but fixes a critical bug in the
areas you *do* use is always going to be a problem that has to be dealt with.

That's one of the reasons numarray hasn't hit the standard library yet - the
Python version release and uptake cycle is too slow for the pace of development
they currently require.

Similarly, this is also part of the reason IDLE went the way of IDLEFork before
being merged back in 2.3 - the development outside the core tree let Kurt and
everyone else involved get it up to speed more quickly.

There's also the fact that monolithic approaches just plain don't scale -
imagining that they can is exactly what leads to the version conflicts that bug
you so much, since developers assume that they don't need to care about
versioning issues, because the packagers will take care of them. In reality, all
it does is move the version conflicts currently noticed by end users and make
the packagers try to deal with them instead - and for some of the problems,
side-by-side installation of multiple version is the only solution, and that's
impossible in the general case without the modules in question providing some
versioning mechanism. And so, once again, we're left with developers having to
worry about dependency issues.

For an example of a well-thought out approach to the versioning issue, take a
look at the work that was done for the recent wxPython release:
http://wiki.wxpython.org/index.cgi/MultiVersionInstalls

What would be ideal is if distutils itself was able to offer a standard package
versioning system. Then all module developers would have to do is be aware of
how to use the distutils versioning system, and installing side-by-side versions
of packages would be create straightforward.

Cheers,
Nick.

--
Nick Coghlan | (E-Mail Removed) | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
 
Reply With Quote
 
 
 
 
Robert Kern
Guest
Posts: n/a
 
      01-08-2005
Scott David Daniels wrote:

> If you can wait, the plan for MacEnthon (Python 2.4 on Mac) looks great:


Actually, just packages for 2.3 (or 2.3.x for Tiger) as of right now.
When someone else packages up 2.4 nicely, I'll start making packages for
that, too.

> http://www.scipy.org/wikis/featurerequests/MacEnthon
>
> I seem to remember discussion about synchronizing with the windows 2.4
> version to have essentially the same list.


They probably won't be synchronized too much. My additions to the list
are primarily for the people I need to support within my organization.
Or my own personal sense of whimsy.

--
Robert Kern
(E-Mail Removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Python evolution: Unease Carlos Ribeiro Python 9 01-07-2005 06:31 AM
Python evolution: Unease Iwan van der Kleyn Python 44 01-07-2005 02:12 AM
Concepts RE: Python evolution: Unease Roman Suzi Python 6 01-06-2005 04:26 AM
Re: Python evolution: Unease Daniel Bowett Python 1 01-05-2005 09:20 PM
Python design strategy (was Python evolution: Unease) ajsiegel@optonline.net Python 1 01-04-2005 07:28 PM



Advertisments