Paul Rubin wrote: > [EMAIL PROTECTED] (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 [EMAIL PROTECTED] "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter -- http://mail.python.org/mailman/listinfo/python-list
