Python -- (just) a successful experiment?

[Robert Kern]

Paul Rubin wrote:
> bkhl at stp.lingfil.uu.se (Björn Lindström) writes:
> 
>>>That would imply that it included the Ruby language. Nothing stops the
>>>Ruby on Rails packagers from making the Ruby on Rails distro a
>>>superset of the Ruby distro, after all.
>>
>>So you agree with me then? That _was_ exactly my point, after all. Not
>>that you read it. After all, you might have been replying to some
>>completely different posting - who could know?
> 
> I don't understand what you're getting at.  Either the RoR
> distribution includes the Ruby language or else it doesn't. 

No. A *particular* Ruby on Rails distribution includes the Ruby 
language. You can get Ruby on Rails by itself if you happen to already 
have Ruby installed. People who aren't just evaluating Ruby on Rails for 
the first time will probably be using the regular distribution.

You'll notice, very distinctly, in big letters at the top of 
http://download.rubyonrails.com :

"Rails is primarily distributed through RubyGems — the soon-to-be 
official packaging format for Ruby libs/apps"

> From that
> other post, I have the impression that it does, but I don't care
> enough about Ruby to want to go check into it.
> 
> Or is your point that some third party could make a moby Python distro
> that includes more runtime stuff than the python.org distro includes?
> Yes, they could; that it's happened with Ruby and not with Python

http://www.enthought.com/python/
http://download.enthought.com/MacEnthon/ReadMe.html

I even pointed you to the last one, earlier.

> suggests that Ruby is doing a better job attracting people to do stuff
> like that.  I don't think the Ruby language is as nice as Python, so
> the difference must be in the culture surrounding the language, rather
> than the language itself.  Python culture often strikes me as
> seriously dysfunctional.  See the "reinventing the wheel" thread of
> the previous week or so, which was full of gnashers arguing that a
> convenient unified distro isn't necessary since users should have
> enough tenacity to download and configure umpteen separate components
> themselves.

As a maintainers of a convenient unified distro, I have to say that it's 
a losing strategy. No matter how much you include, for every person that 
tells you, "Thank you, you've made my Python experience better," there 
are three who say, "Thanks, but could you also include Package X?" or 
"Thanks, but Package Y is much better at doing foo than Package Z? Could 
you include it next time?" or "When are you going to update Package W to 
the latest version?"

You can't satisfy everyone or even a whole lot of people with a single 
massive installer. People want different things. I want VTK installed 
because I need 3D visualization; I couldn't care less about web 
applications. But lots of other people care very deeply about web 
applications and don't want to waste 100 MB of disk space on 3D 
visualization libraries.

When "one-click installation" entails downloading 150 MB of compressed 
data for every update, the convenience begins to pall a bit.

Fortunately, there's a better approach, and it's coming soon. The next 
iteration of MacEnthon, at least, is going to be based on Python eggs 
and easy_install.py. Python eggs are, more or less, Python's answer to 
Ruby's gems.

http://peak.telecommunity.com/DevCenter/PythonEggs
http://peak.telecommunity.com/DevCenter/EasyInstall

-- 
Robert Kern
rkern at ucsd.edu

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