RailsInstaller?
rubys
hurt to ask.
First a brief introduction. My name is Sam Ruby, one of the authors
of Agile Web Development With Rails:
http://www.pragprog.com/titles/rails3/agile-web-development-with-rails-third-edition
, which is the book that is mentioned here: http://rubyonrails.org/
Currently (as of the 3rd edition), the book recommends starting with
InstantRails and upgrading the version of Gems and Rails. As the next
edition of the book will focus on Rails 3.0 which requires Ruby 1.8.7,
this is no longer practical (InstantRails ships Ruby 1.8.6).
http://intertwingly.net/blog/2010/02/01/Rails-3-0-on-Cygwin
I've been able to test using Cygwin and can include those
instructions, but I would prefer to point to something that is more
native and integrated with the operating system.
What would be ideal for me is something that was at most a "gem
install rails" away from being up and running.
At a minimum, I can provide help in testing and reporting bugs. An
example of the automated testing that I currently do on Ubuntu:
http://intertwingly.net/projects/dashboard.html
Is this something you (collectively) would be interested in?
- Sam Ruby
Luis Lavena
On Wed, Feb 3, 2010 at 2:20 AM, rubys <ru...@intertwingly.net> wrote:
> I don't know if this request is reasonable, but I figured it wouldn't
> hurt to ask.
>
> First a brief introduction. My name is Sam Ruby, one of the authors
> of Agile Web Development With Rails:
> http://www.pragprog.com/titles/rails3/agile-web-development-with-rails-third-edition
> , which is the book that is mentioned here: http://rubyonrails.org/
>
Hello Sam, I think I read your first edition book already :)
> Currently (as of the 3rd edition), the book recommends starting with
> InstantRails and upgrading the version of Gems and Rails. As the next
> edition of the book will focus on Rails 3.0 which requires Ruby 1.8.7,
> this is no longer practical (InstantRails ships Ruby 1.8.6).
>
> http://intertwingly.net/blog/2010/02/01/Rails-3-0-on-Cygwin
>
> I've been able to test using Cygwin and can include those
> instructions, but I would prefer to point to something that is more
> native and integrated with the operating system.
Yes, cygwin may be familiar with Linux/*nix developers but is not so
nice in performance.
> What would be ideal for me is something that was at most a "gem
> install rails" away from being up and running.
>
Right now we "officially" ship 2 versions: 1.8.6 and 1.9.1
Getting started with Rails and RubyInstaller can be checked out here:
http://blog.mmediasys.com/2009/07/06/getting-started-with-rails-and-mysql/
I'm waiting from Kirk Haines in updated 1.8.6 (was not compilable) so
a newer release of 1.8.6 and 1.9.1 with fixes to the installer process
can be done.
InstantRails is based on old One-Click Installer, but basically they
could switch to RubyInstaller and bundle the binaries instead of the
One-Click without too much modifications.
Taking in consideration newer version of Rails will require 1.8.7,
I've been looking into getting it to build and compile properly with
our current set of recipes.
So, this means:
* Once Kirk Haines releases a newer 1.8.6 patchlevel, RubyInstaller
RC2 will be released
* New RubyInstaller RC2 will include patches to the installer process
* It will also ship 3 versions: 1.8.6, 1.8.7 and 1.9.1
1.8.6 will remain as is the main version I use and our remote servers
do, so will remain build by me and supported by EngineYard.
> At a minimum, I can provide help in testing and reporting bugs. An
> example of the automated testing that I currently do on Ubuntu:
>
> http://intertwingly.net/projects/dashboard.html
>
> Is this something you (collectively) would be interested in?
>
Definitely!
if you find a way to make Erbshim works on Windows, results from that
will be great to have.
Also, you will have to test both 1.8.6 and 1.9.1, or maybe 1.8.7 when
released to be able to have 3.0.pre working.
We're been working in improve the usage of Ruby through RubyInstaller,
not just focused on Rails, but any feedback will be appreciated.
Thank you for your time and keep an eye on announcement about RC2 soon
this weekend (if things move good in Ruby front).
Cheers,
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry
Sam Ruby
>
> Also, you will have to test both 1.8.6 and 1.9.1, or maybe 1.8.7 when
> released to be able to have 3.0.pre working.
Just so it is clear: 3.0 will not work at all (will not boot) if run
with Rails 1.8.6. 1.8.6 is not an option. Rails 3.0 also won't work
with the first patch level of 1.9.1, so officially the Rails team is
looking at only supporting 1.8.7 and 1.9.2 (once it comes out).
- Sam Ruby
Luis Lavena
Versions that will be released as RubyInstaller:
1.8.6, for existing support from lot of servers
1.8.7, for Rails 3.0.pre and moving forward
1.9.1, for 1.9 branch for people wanting to get hands dirty with Encoding.
I know my english is not good, please let me know if this is clear now.
Jon
> > Rails 1.8.6. 1.8.6 is not an option. Rails 3.0 also won't work with the
> > first patch level of 1.9.1, so officially the Rails team is looking at only
> > supporting 1.8.7 and 1.9.2 (once it comes out).
> >
>
> Versions that will be released as RubyInstaller:
>
> 1.8.6, for existing support from lot of servers
> 1.8.7, for Rails 3.0.pre and moving forward
> 1.9.1, for 1.9 branch for people wanting to get hands dirty with Encoding.
>
> I know my english is not good, please let me know if this is clear now.
RubyInstaller RC2 (in both .exe installer and .7z archive) still targeting patch levels 1.8.6p???, 1.8.7p248 and 1.9.1p376, correct?
Luis Lavena
>
> RubyInstaller RC2 (in both .exe installer and .7z archive) still targeting patch levels 1.8.6p???, 1.8.7p248 and 1.9.1p376, correct?
>
Didn't I say that?
Yes: RC2 will provide binaries for 1.8.6 latest patchlevel (when
available) and latest patchlevels of 1.8.7 and 1.9.1 at the time the
installers are created.
Jon
> install rails" away from being up and running.
>
> At a minimum, I can provide help in testing and reporting bugs. An
> example of the automated testing that I currently do on Ubuntu:
>
> http://intertwingly.net/projects/dashboard.html
>
> Is this something you (collectively) would be interested in?
Your dashboard page and corresponding drill down pages are nice.
A few thoughts after browsing your site:
1) Your http://intertwingly.net/blog/2010/02/01/Rails-3-0-on-Cygwin post links "RubyInstaller" to the RubyForge site. While technically correct, it's not our primary site and I'd like to request the "RubyInstaller" link (like the the "underway" link) be updated to http://rubyinstaller.org/ Even though this new site is really a placeholder until will we stand up our real site, I think you'll agree it's a bit nicer and easier to use than RubyForge and it links into our main GitHub project pages.
FYI, James has graciously updated "Ruby on Windows" section of http://www.ruby-lang.org/en/downloads/ for me to make things a bit more clear wrt RubyInstaller including key dependencies that the Windows archive from ruby-core does not.
As you note in your post, things can be a bit of a dependency scavenger hunt. However, it's not entirely clear from the post that the scavenger hunt is only applicable to core's VC6 compiled archives, not the MinGW-compiled RubyInstaller. I think one of the key ease-of-use features of the RubyInstaller is the bundling of key dependencies. Any clarification on your blog would be much appreciated.
2) Do you have a windows system to run your Depot Dashboard tests against? I know it would be extra work, but a Depot Dashboard for windows using the RubyInstaller's would be great and I'd like to see us link to from our project wiki page at http://wiki.github.com/oneclick/rubyinstaller/
3) If you're not already aware, the pik gem from Gordon at http://github.com/vertiginous/pik/ is a great tool for switching between various Ruby impl's on your windows system. Very useful for quickly testing against IronRuby, JRuby, RubyInstaller patches, etc.
4) Interestingly, your dashboard shows 1.9.1 working with 3.0pre. What patch 1.9.1 patch level and do you think Rails 3.0 will work and be supported by the Rails team on 1.9.1p376?
Jon
Sam Ruby
>> What would be ideal for me is something that was at most a "gem
>> install rails" away from being up and running.
>>
>> At a minimum, I can provide help in testing and reporting bugs. An
>> example of the automated testing that I currently do on Ubuntu:
>>
>> http://intertwingly.net/projects/dashboard.html
>>
>> Is this something you (collectively) would be interested in?
>
> Your dashboard page and corresponding drill down pages are nice.
>
> A few thoughts after browsing your site:
>
> 1) Your http://intertwingly.net/blog/2010/02/01/Rails-3-0-on-Cygwin
> post links "RubyInstaller" to the RubyForge site. While technically
> correct, it's not our primary site and I'd like to request the
> "RubyInstaller" link (like the the "underway" link) be updated to
> http://rubyinstaller.org/ Even though this new site is really a
> placeholder until will we stand up our real site, I think you'll
> agree it's a bit nicer and easier to use than RubyForge and it links
> into our main GitHub project pages.
I've tried to clarify, let me know if I got it right.
> FYI, James has graciously updated "Ruby on Windows" section of
> http://www.ruby-lang.org/en/downloads/ for me to make things a bit
> more clear wrt RubyInstaller including key dependencies that the
> Windows archive from ruby-core does not.
Cool.
> As you note in your post, things can be a bit of a dependency
> scavenger hunt. However, it's not entirely clear from the post that
> the scavenger hunt is only applicable to core's VC6 compiled
> archives, not the MinGW-compiled RubyInstaller. I think one of the
> key ease-of-use features of the RubyInstaller is the bundling of key
> dependencies. Any clarification on your blog would be much
> appreciated.
I've tried to clarify this too.
> 2) Do you have a windows system to run your Depot Dashboard tests
> against? I know it would be extra work, but a Depot Dashboard for
> windows using the RubyInstaller's would be great and I'd like to see
> us link to from our project wiki page at
> http://wiki.github.com/oneclick/rubyinstaller/
I do have a system that I can reboot to windows (that's how I tested
cygwin). I started testing with RubyInstaller's version, and hit a
number of issues which I'm slowly working through. ($stdin.eof? doesn't
seem to be reliable, I get EOFError, no fork, things like that).
And then there still is the issue of gems like sqlite3-ruby, erubis,
json, ...
> 3) If you're not already aware, the pik gem from Gordon at
> http://github.com/vertiginous/pik/ is a great tool for switching
> between various Ruby impl's on your windows system. Very useful for
> quickly testing against IronRuby, JRuby, RubyInstaller patches, etc.
Was not aware of that. Cool. I'm using rvm on Ubuntu.
> 4) Interestingly, your dashboard shows 1.9.1 working with 3.0pre.
> What patch 1.9.1 patch level and do you think Rails 3.0 will work and
> be supported by the Rails team on 1.9.1p376?
I think it will work with p376, but the Rails team may only edit up
supporting 1.9.2. (At the end of each run's output is full details on
what gems and version of ruby and versions of rails I'm running with).
> Jon
- Sam Ruby
Luis Lavena
>
> I do have a system that I can reboot to windows (that's how I tested
> cygwin). I started testing with RubyInstaller's version, and hit a number
> of issues which I'm slowly working through. ($stdin.eof? doesn't seem to be
> reliable, I get EOFError, no fork, things like that).
>
If $stdin.eof? works differently between VC6 (One-Click Installer or
the version bundled by InstantRails) from RubyInstaller builts, then
is a bug of Ruby.
If $stdin.eof? works differently from cygwin: that is intended, is not
a posix emulation and should not be executed inside a posix prompt or
form a posix environment.
There is no fork() in Windows, cygwin is hacking something to mimic
it, but is slow and unreliable.
> And then there still is the issue of gems like sqlite3-ruby, erubis, json,
> ...
Please let me know the issues with these gems. With RubyInstallers
there are binaries for sqlite3-ruby and even json, and if not,
installing the DevKit on top of a working RubyInstaller should provide
the building blocks to compile most of the gems that lack pre-built
binaries.
http://wiki.github.com/oneclick/rubyinstaller/development-kit
>
>> 3) If you're not already aware, the pik gem from Gordon at
>> http://github.com/vertiginous/pik/ is a great tool for switching
>> between various Ruby impl's on your windows system. Very useful for
>> quickly testing against IronRuby, JRuby, RubyInstaller patches, etc.
>
> Was not aware of that. Cool. I'm using rvm on Ubuntu.
>
Pik started almost at the same time of RVM, basically you can say "is
RVM for Windows" ;-)
Jon
Thank you.
> I do have a system that I can reboot to windows (that's how I tested
> cygwin). I started testing with RubyInstaller's version, and hit a
> number of issues which I'm slowly working through. ($stdin.eof? doesn't
> seem to be reliable, I get EOFError, no fork, things like that).
>
> And then there still is the issue of gems like sqlite3-ruby, erubis,
> json, ...
As Luis mentioned, the DevKit (MSys+MinGW) enables Windows users to build many of the native C-based Ruby extensions available. Currently we're using http://wiki.github.com/oneclick/rubyinstaller/gem-list to track the status of many of those and we plan to move to a more maintainable DB-driven page rather than the horrible textile/wiki. Please let us know if you have issues with other native gems as well as update the list.
FYI, Luis has also made available the rake-compiler gem which, in a nutshell, enables Linux and MacOS developers to cross-compile binary gems (and "fat binary" 1.8/1.9) for windows users. It's currently used by the Nokokiri, FFI, Amalgalite and other developers. Luis is either being too modest or he's too busy pushing out RC2 to mention this I guess ;)
Jon
Charles Roper
> FYI, Luis has also made available the rake-compiler gem which, in a nutshell, enables Linux and MacOS developers to cross-compile binary gems (and "fat binary" 1.8/1.9) for windows users. It's currently used by the Nokokiri, FFI, Amalgalite and other developers. Luis is either being too modest or he's too busy pushing out RC2 to mention this I guess;)
Perhaps we should also mention that the community voted (Luis ran a
poll) for DevKit to be gemified in order to ease installation (it's
currently a bit fiddly and could scare new users who are trying to
install gems that depend on it, such as RedCloth).
Sam, in order to greatly simplify your Cygwin instructions, you might
want to take a look at cygwin-setup-p.exe which is a modified installer
that can take arguments in order to bybass the UI and its associated
complexity. It was created by Alexander Stigsen, author of E Text
Editor, in order to quietly install Cygwin and packages unattended.
You can grab it here:
http://code.google.com/p/ebundles/source/browse/#svn/trunk/Support/bin
Instructions:
http://code.google.com/p/ebundles/wiki/SupportDir
Charles
Sam Ruby
That apparently adds a "-p" option? The version of setup that you get
from CYGWIN supports a "-P" option that seems to do the same thing (and,
yes, it appears to be case sensitive). I use the following:
http://intertwingly.net/stories/2010/02/01/newcygwin.bat
http://intertwingly.net/stories/2010/02/01/newcygwin.sh
My goal is to produce equally as simple (and ideally simpler)
instructions using RubyInstaller.
- Sam Ruby
> Charles
>
Luis Lavena
>
> That apparently adds a "-p" option? The version of setup that you get from
> CYGWIN supports a "-P" option that seems to do the same thing (and, yes, it
> appears to be case sensitive). I use the following:
>
> http://intertwingly.net/stories/2010/02/01/newcygwin.bat
> http://intertwingly.net/stories/2010/02/01/newcygwin.sh
>
> My goal is to produce equally as simple (and ideally simpler) instructions
> using RubyInstaller.
>
> - Sam Ruby
>
Well, all that can be automated for the installation of Ruby (using
RubyInstaller executable) to the gem installation process.
InnotSetup, the system used to build the installer is pretty
extensible, and can be worked out to create custom installers that
automate these tasks, maybe to the point of creating "RailsInstaller"
based on RubyInstaller.
Would you mind testing out the hacky guides I wrote for Ruby 1.8.6 and
Rails 2.3.4 with your depot application?
Sqlite3/Ruby should work, gems should install and compile fine with
DevKit installed.
I believe RubyInstaller compared to your updated instructions for
Cygwin differ a lot.
As for Rails 3, next week there will be news in RubyInstaller from in
relation to available versions. Right now Daily Work(tm) has taken me
over.
Regards,
Sam Ruby
> On Wed, Feb 3, 2010 at 8:13 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>> That apparently adds a "-p" option? The version of setup that you get from
>> CYGWIN supports a "-P" option that seems to do the same thing (and, yes, it
>> appears to be case sensitive). I use the following:
>>
>> http://intertwingly.net/stories/2010/02/01/newcygwin.bat
>> http://intertwingly.net/stories/2010/02/01/newcygwin.sh
>>
>> My goal is to produce equally as simple (and ideally simpler) instructions
>> using RubyInstaller.
>>
>> - Sam Ruby
>
> Well, all that can be automated for the installation of Ruby (using
> RubyInstaller executable) to the gem installation process.
Except for things like sqlite3 itself....
> InnotSetup, the system used to build the installer is pretty
> extensible, and can be worked out to create custom installers that
> automate these tasks, maybe to the point of creating "RailsInstaller"
> based on RubyInstaller.
That would be ideal! And could include things like sqlite3...
> Would you mind testing out the hacky guides I wrote for Ruby 1.8.6 and
> Rails 2.3.4 with your depot application?
If you are talking about this:
http://blog.mmediasys.com/2009/07/06/getting-started-with-rails-and-sqlite3/
Then that is what I was looking for, and for some reason was unable to
find previously.
As to 2.3.4, it will be several days before I can get to that; and
likely next week.
> Sqlite3/Ruby should work, gems should install and compile fine with
> DevKit installed.
>
> I believe RubyInstaller compared to your updated instructions for
> Cygwin differ a lot.
What I was looking for is something like your blog post on mmediasys.com.
> As for Rails 3, next week there will be news in RubyInstaller from in
> relation to available versions. Right now Daily Work(tm) has taken me
> over.
Ditto. Given that Rails 3 is literally hours away, what I am likely to
do first is try Rails 3 on an RC (knowing full well that what I am
trying is something nobody has tried before, and will likely not work
the first time), and report back on problems I see in the hopes that
that will be helpful.
> Regards,
- Sam Ruby
Gordon Thiesfeld
What I was looking for is something like your blog post on mmediasys.com.
http://matt-hulse.com/articles/2010/01/30/from-zero-to-rails3-on-windows-in-600-seconds/
Gordon
Roy Pardee
Luis Lavena wrote:Except for things like sqlite3 itself....
On Wed, Feb 3, 2010 at 8:13 PM, Sam Ruby <ru...@intertwingly.net> wrote:
Well, all that can be automated for the installation of Ruby (using
RubyInstaller executable) to the gem installation process.
That would be ideal! And could include things like sqlite3...
InnotSetup, the system used to build the installer is pretty
extensible, and can be worked out to create custom installers that
automate these tasks, maybe to the point of creating "RailsInstaller"
based on RubyInstaller.
Is the issue preventing a simple "gem install rails" post-rubyinstaller that the canonical sqlite gem is not a 'fat binary'? Or are there binaries you need to install separately even on *nix?
If the former, would it make sense/be feasible to tweak the gem install so that the fat binary source is one of the sources the gem command looks to (so--remove the need for the --source param on the gem install command)? Or would that take pressure off authors to do their own fat binaries?
IMHO, you should strive for as uniform an experience across *nix/windows as possible. Instant Rails was great, but I think it created another class of windows ppl who considered themselves too dumb to work w/real install/config.
As usual--thanks everybody for your hard work!
Roy Pardee
http://facebook.com/rpardee
Luis Lavena
>
> Except for things like sqlite3 itself....
>
Gem installation can be automated, however, just to be crystal clear:
gem install sqlite3-ruby
the sqlite3 gem is not sqlite3-ruby
Sam Ruby
> On Thu, Feb 4, 2010 at 3:38 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>> Except for things like sqlite3 itself....
>
> Gem installation can be automated, however, just to be crystal clear:
>
> gem install sqlite3-ruby
>
> the sqlite3 gem is not sqlite3-ruby
And (just be equally crystal clear): sqlite3-ruby is useless without
http://www.sqlite.org/download.html.
I'm spoiled because I use Ubuntu. apt-get install rails will install
everything I need: ruby, sqlite3, everything.
Given that sqlite3 (the database itself, not the rubygem interface to
same) is small, open source, and redistributable, I think it would be
ideal if it were included in the RailsInstaller bundle for Windows users.
- Sam Ruby
Charles Roper
> IMHO, you should strive for as uniform an experience across *nix/windows
> as possible. Instant Rails was great, but I think it created another
> class of windows ppl who considered themselves too dumb to work w/real
> install/config.
Yeah, which is kind of strange considering Ruby and Rails are heavily
oriented around the command line. I always thought InstantRails was kind
of creating a false expectation of Rails; an incorrect initial impression.
That said, it makes sense to make the installation process on Windows as
painless and straightforward as possible. The way I believe it *should*
work is this:
1. Install Ruby + DevKit via the RubyInstaller as a one-step process
2. At the command line, run
> gem install sqlite3-ruby rails
Regarding #1, it would seem to make sense for the DevKit to be installed
as part of the basic Ruby install so that the maximum number of gems
install out-of-the-box. RedCloth springs to mind as a gem that requires
the DevKit. Luis, is there any reason why the DevKit isn't, or shouldn't
be, installed as part of the basic install?
Regarding #2, is it not possible to extend the sqlite3-ruby gem to
enable download, installation and possibly update of the sqlite binaries
in the same way Pik enables dead simple installation of JRuby and
IronRuby? This might require a third step to be added to the above steps:
3. At the command line, run
> sqlite3-ruby install
Alternatively, can the binaries not be installed as part of the gem
installation itself?
As usual my questions are probably naive, but that's probably useful as
I'm trying to view the experience through the eyes of a inexperienced
users coming to these things for the first time.
Charles
Jon
> as part of the basic Ruby install so that the maximum number of gems
> install out-of-the-box. RedCloth springs to mind as a gem that requires
> the DevKit. Luis, is there any reason why the DevKit isn't, or shouldn't
> be, installed as part of the basic install?
I agree there are nice reasons for bundling things together like the DevKit and the base RubyInstaller, but the biggest reasons I'm not for the idea are (a) long term maintainability, and (b) separation of concerns/resourcing.
I personally prefer:
1) RubyInstaller as-is
2) DevKit installer after fleshing out Luis and Alexey's discussion at http://groups.google.com/group/rubyinstaller/browse_thread/thread/dd986e22ea3c9dbb
3) Sam's RailsInstaller idea in which SQLite could be easily bundled
(2) and (3) can be resourced, maintained, and evolved more independently than bundles of them
Jon
Luis Lavena
<rea...@charlesroper.co.uk> wrote:
> [...]
>
> That said, it makes sense to make the installation process on Windows as
> painless and straightforward as possible. The way I believe it *should*
> work is this:
>
> 1. Install Ruby + DevKit via the RubyInstaller as a one-step process
> 2. At the command line, run
>
>> gem install sqlite3-ruby rails
>
> Regarding #1, it would seem to make sense for the DevKit to be installed as
> part of the basic Ruby install so that the maximum number of gems install
> out-of-the-box. RedCloth springs to mind as a gem that requires the DevKit.
> Luis, is there any reason why the DevKit isn't, or shouldn't be, installed
> as part of the basic install?
>
This is some sort of covered on previous conversations in the mailing
list. Latest bug reports around "DevKit is not an installer" bring the
known issue once again.
Will get that covered soon, but didn't wanted to impose the DevKit
which is +12MB for some users that only wants Ruby, not compile
extensions or anything.
For example, doing Win32OLE can work out of the box, no need for
external dependencies. Why add 12MB to an already 10MB download for
just scripting?
> Regarding #2, is it not possible to extend the sqlite3-ruby gem to enable
> download, installation and possibly update of the sqlite binaries in the
> same way Pik enables dead simple installation of JRuby and IronRuby? This
> might require a third step to be added to the above steps:
>
> 3. At the command line, run
>
>> sqlite3-ruby install
>
> Alternatively, can the binaries not be installed as part of the gem
> installation itself?
>
The binaries and be bundled in the gem, as long you honor the
licensing and statements for the binaries gems.
If you take look to Nokogiri, it tweaks the PATH, which is wrong.
I've expressed these initial details here:
http://rubyforge.org/pipermail/rubygems-developers/2008-November/004256.html
> As usual my questions are probably naive, but that's probably useful as I'm
> trying to view the experience through the eyes of a inexperienced users
> coming to these things for the first time.
>
While you think is naive is quite useful and valuable, which I believe
we all appreciate.
The out of the box experience offered by things like InstantRails and
Locomotive had their own set of issues.
What I originally intended for RubyInstaller is remove that painless
experience bit by bit, piece by piece, it is a hard task and there are
so many moving parts and tastes to please that sometimes slow you
down.
Jon
> Regarding #1, it would seem to make sense for the DevKit to be installed as
> part of the basic Ruby install so that the maximum number of gems install
> out-of-the-box. RedCloth springs to mind as a gem that requires the DevKit.
> Luis, is there any reason why the DevKit isn't, or shouldn't be, installed
> as part of the basic install?
>
IMO, getting a DevKit installer (a Good Thing) in a timely manner in addition to the current 7z archive (also a Good Thing) is more about someone taking the lead on this sub-project. I don't think that person should be Luis as I feel he's already put too much on his plate. Adding the DevKit installer would be defocusing and likely slow RC2 and Final down. As we all know, there's only so much time available with Paid Work, Real Life, and Unpaid OSS Contributions.
My vote is for Alexey (if he's interested and has the time to make the commitment) to take lead, drive it, and request assistance if he needs it to speed up delivery.
> Regarding #2, is it not possible to extend the sqlite3-ruby gem to enableThe binaries and be bundled in the gem, as long you honor the
> download, installation and possibly update of the sqlite binaries in the
> same way Pik enables dead simple installation of JRuby and IronRuby? This
> might require a third step to be added to the above steps:
>
> 3. At the command line, run
>
>> sqlite3-ruby install
>
> Alternatively, can the binaries not be installed as part of the gem
> installation itself?
>
licensing and statements for the binaries gems.
I really like Sam's original suggestion of a RailsInstaller. It could be an installer leveraging the existing work and at a minimum be RubyInstaller (1.8.7 or 1.9.1) and Rake + sqlite3-ruby + Thin/Eventmachine + Rails as bundled gems. I think there could be 99% reuse of our existing Inno Installer scripts with the bulk of the work would be (a) tweaking the existing Rake-based build scripts, and (b) some cool installer graphics rather than the default.
The goal would be to continually leverage the RubyInstaller project for build infrastructure updates and enable someone to focus on integrating a baseline Rails config for those who don't want to go through the 3 step process of (a) install RubyInstaller, (b) "gem install rails", and (c) copy sqlite.dll to "bin" and "gem install sqlite3-ruby"
The obvious questions of course are, "Does a RailsInstaller really add any value over great install documentation?" and "Why not just do a refresh of the existing InstantRails project (rather than starting a new one) since it already is a known brand?"
IMO the lead (not Luis for the same reasons as above) should be someone who consistently works with Rails on a daily basis and has a vested interest in seeing it work well on Windows with MRI Ruby, rather than someone who is merely interested and could tire of the time commitment needed to sustain a new RailsInstaller project.
I don't have any thoughts on the lead, but I do know that it's a great opportunity for someone to collaborate with Sam (if he's open and able) to make a really cool Rails on Windows experience AND have it tied in with Sam's book and his experience with Rails. Very cool. I wish I had sustainable work with Rails and could pick it up :( I'll offer up help with Inno scripting mods and some graphics if that would add value.
Andrew Shebanow
share some of the investigations I've been doing along these lines -
pardon me if this is too much of a digression.
I run the engineering group working on RadRails 3 at Aptana, and we're
trying to build a more seamless first-time-install process for Rails
newbies. Ideally, we'd like to have someone who downloads RadRails to
get a seamless install experience: you get RadRails, you also get
ruby, rails, sqlite3, and git (I think its interesting that no one has
mentioned git so far, when its becoming increasingly difficult to work
with ruby gems without the ability to use git: urls...). We could
easily build such an experience on top of RubyInstaller/DevKit and
msysgit, but what do we do about users who already have cygwin or the
ruby-lang-org version of rails installed?
What we're thinking is that we'll check for cygwin and if you use it
you are on your own. Then we'll check for ruby and git on the path and
install those as needed. Once we know we have a version of ruby and
git we'll install rails and sqlite for you within that install.
As an aside, we also have a built in terminal within RadRails 3. On
windows, we actually have to install our own cygwin subset in order to
get the posix readline behavior we need in order to make an embedded
command prompt work... It is pretty gross, but getting nice command
prompt behavior on Windows is surprisingly difficult. We'd have loved
to have been able to use the bash provided with the RubyInstaller
since that would have given us a single msys/mingw environment
throughout, but it doesn't provide the IO behavior we need.
In any event, we'd like to hear from others about what they are doing
to help make the first-time-install experience on windows better. We'd
love it if the devkit install was automatable.