I’m on 1.8, maybe you can create/fork csv2 on 1.8 wc is then
compatible w your 1.9 csv?
you deprecate curr 1.8 csv.
you develop csv2 1.8 or csv 1.9.
I’ll release the new csv module as csv/1.3.0 at http://raa.ruby-lang.org/project/csv/ for 1.6/1.8. The installer of it
should install csv.rb as csv2.rb for ruby/1.8.* ?
But… If there isn’t any comment more, can I simply replace 1.8’s
csv.rb with the new one? Peña won’t be surprised with the API change.
What do other users think?
The goal of the project on OS X is to have Ruby installed as a
.framework, as Apple has already done with Python for OS X and to
include a collection of tools to make Ruby an integral part of the
system.
Eventually, as they did with Python, we want to merge the framework
build with the main Ruby distribution so that anyone using the default
build on OS X will get the framework version.
Would you be able to include Rpa-base as well? I just
completed a project and it would be nice for them to
be able to install the libraries I want via RPA.
Thanks
The goal of the project on OS X is to have Ruby
installed as a
.framework, as Apple has already done with Python
for OS X and to
include a collection of tools to make Ruby an
integral part of the
system.
Eventually, as they did with Python, we want to
merge the framework
build with the main Ruby distribution so that anyone
using the default
build on OS X will get the framework version.
We are planning on including a native version of the
RubyGems
GemBrowserGui
The goal of the project on OS X is to have Ruby installed as a
framework, as Apple has already done with Python for OS X and to
include a collection of tools to make Ruby an integral part of the
system.
Could you go into a bit more detail about what it would mean to 'have Ruby
installed as a framework' vs how it is done now? I'm not too sure I know
what 'framework' means in this sense.
Eventually, as they did with Python, we want to merge the framework
build with the main Ruby distribution so that anyone using the default
build on OS X will get the framework version.
Would you be able to include Rpa-base as well? I just
completed a project and it would be nice for them to
be able to install the libraries I want via RPA.
Thanks
--David Ross
This is a serious possibility at some point, but not for the next release
(Windows or OS X). At the moment we have our hands full.
Curt
···
--- Stephen Steiner <ssteiner@mac.com> wrote:
> I have begun work on a version of the One-Click Ruby
> Installer for Mac
> OS X. See the wiki at:
> http://rubyinstaller.rubyforge.org.
>
> The goal of the project on OS X is to have Ruby
> installed as a
> .framework, as Apple has already done with Python
> for OS X and to
> include a collection of tools to make Ruby an
> integral part of the
> system.
>
> Eventually, as they did with Python, we want to
> merge the framework
> build with the main Ruby distribution so that anyone
> using the default
> build on OS X will get the framework version.
>
> We are planning on including a native version of the
> RubyGems
> GemBrowserGui
>
(http://rubygems.rubyforge.org/wiki/wiki.pl?GemBrowserGui\)
> which we
> will probably develop using RubyCocoa
> (http://www.fobj.com/rubycocoa/doc/\).
>
> The list of utilities we will include in the
> installer will grow once
> we get the base installer and GemBrowserGui done.
>
> Help Wanted! Please see the OS X One-Click Ruby
> Installer for OS X
> wiki at:
> http://rubyinstaller.rubyforge.org/wiki/wiki.pl?Steve_Steiner
>
> Thanks and see you on the wiki!
>
> Steve
>
>
>
We are working on getting Ruby working as a framework, then we'll tackle the RubyGems GUI.
Once that's working, we will be evaluating other options.
<personal_opinion>
One of things that I, personally, would like to accomplish while doing this installer is to unite the various "Not Quite CPAN" things floating around in the Ruby community that I believe fragment the "Ruby Universe" in a detrimental way.
While they don't necessarily need to be perfectly united, a GUI that made them appear that way would go a long way towards jumping over what I'll coiningly call "The CPAN Hurdle".
</personal_opinion>
At this point, we're needing some help with the basic setup of Ruby as a framework. The Python framework makefile has a large section with the ominous title:
# Fixup a lot of problems after the install
Anyone with any contacts inside or outside Apple, or with any contacts to people who worked on or understand the "Fixup part" of the Python makefile are encouraged to join in.
Would you be able to include Rpa-base as well? I just
completed a project and it would be nice for them to
be able to install the libraries I want via RPA.
Thanks
The goal of the project on OS X is to have Ruby
installed as a
.framework, as Apple has already done with Python
for OS X and to
include a collection of tools to make Ruby an
integral part of the
system.
Eventually, as they did with Python, we want to
merge the framework
build with the main Ruby distribution so that anyone
using the default
build on OS X will get the framework version.
We are planning on including a native version of the
RubyGems
GemBrowserGui
Could you go into a bit more detail about what it would mean to 'have Ruby
installed as a framework' vs how it is done now? I'm not too sure I know
what 'framework' means in this sense.
In Panther, Apple chose to install Python as a framework in /Library/Python. It was installed in the traditional /usr/bin in previous versions of OS X. The framework install is now the standard when Python is built on OS X from source as distributed by python.org.
A framework is a self-contained directory tree that contains a shared product. It is analogous to an application bundle but contains shared resources (library, utilities, etc.) rather than an application which contains only the things related to the application. Multiple versions of a framework can be safely installed side-by-side.
Are you hoping to get Apple to include all of this in Tiger (or perhaps a later version of Tiger)?
Yes, one of the primary goals of this project is to make Apple's installation of Ruby on Tiger on a par (at least!) with the current Python install on Panther.