Wrapping things for 1.9.2-p0 - use-devkit
Luis Lavena
I wanted to push forward with use-devkit branch and I'm working now in
ensure it compiles and works with 1.9.2-p0 that was released a few
hours ago.
If nobody objects, I would like merge use-devkit branch to master and
be the foundation for newer installers.
This means 1.9.2-p0 will go out with GCC 4.5.0, which will require
newer DevKit. Experimental DevKit is out at GitHub, but more work is
needed.
I would like to avoid holding 1.9.2 release for long time, specially
since lot of people is waiting for it.
What do you guys think?
--
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
Jon
> ensure it compiles and works with 1.9.2-p0 that was released a few
> hours ago.
>
> If nobody objects, I would like merge use-devkit branch to master and
> be the foundation for newer installers.
>
> This means 1.9.2-p0 will go out with GCC 4.5.0, which will require
> newer DevKit. Experimental DevKit is out at GitHub, but more work is
> needed.
I successfully build 1.9.2-p0 with the use-devkit branch and have been experimenting with rails-3.0.0.rc and other things.
While there's a bit more polishing needed on the newer DevKit, I've heard of no hard failures and one can always build it with "rake devkit sfx=1", or download one of the experimental versions from our GitHub project page.
I vote for merging and releasing :)
Jon
Boško Ivanišević
Hello,
I wanted to push forward with use-devkit branch and I'm working now in
ensure it compiles and works with 1.9.2-p0 that was released a few
hours ago.
If nobody objects, I would like merge use-devkit branch to master and
be the foundation for newer installers.
This means 1.9.2-p0 will go out with GCC 4.5.0, which will require
newer DevKit. Experimental DevKit is out at GitHub, but more work is
needed.
I would like to avoid holding 1.9.2 release for long time, specially
since lot of people is waiting for it.
What do you guys think?
--
Regards,
Boško Ivanišević
Chuck Remes
Luis Lavena
Thank you guys.
I just tested the merge and everything worked as expected.
I'm not going to release 1.9.2-p0 installers yet, want to better
document the switch of GCC and what DevKit should be used instead.
Dušan Majkić
Devkit completly changed my ruby experience on the windows platform.
It should be made available as default with rubyinstaller, or as an
easy add-on or gem.
Luis Lavena
Thank you for your comment Dušan, we have another thread there we
discussed the DevKit approach and decided a separate installer will be
available.
That will give the option for further customization of deployment scenarios.
Robert Calco
I totally agree with that. Should be part of the distro... Without it Ruby's value proposition on Windows would be "less than" that of Ruby on any other platform. I've found the inability to install certain gems without a binary-compatible compiler to be a bit like trying to brush your teeth without a toothbrush. Like decaffinated coffee.. or non-alcoholic beer... or non-adhesive tape...
Seriously... Ruby should "just work" out of the box. Even on Windows. Please include the DevKit!
- Bob
--
You received this message because you are subscribed to the Google Groups "RubyInstaller" group.
To post to this group, send email to rubyin...@googlegroups.com.
To unsubscribe from this group, send email to rubyinstalle...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyinstaller?hl=en.
Robert Calco
2010/8/19 Dušan Majkić <dma...@gmail.com>:
>> What do you guys think?Thank you for your comment Dušan, we have another thread there we
>
> Devkit completly changed my ruby experience on the windows platform.
>
> It should be made available as default with rubyinstaller, or as an
> easy add-on or gem.
>
discussed the DevKit approach and decided a separate installer will be
available.
That will give the option for further customization of deployment scenarios.
OK, at least make it an optional part of the installation. By default checked!
I for one cannot fathom when I would ever NOT want the compiler, even if was a production deployment scenario. Only if I forgo the use of many great gems that are written or require C extensions. Why would I do that?
- Bob
--
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
--
Luis Lavena
>
> 2010/8/19 Dušan Majkić <dma...@gmail.com>
>>
>> > What do you guys think?
>>
>> Devkit completly changed my ruby experience on the windows platform.
>>
>> It should be made available as default with rubyinstaller, or as an
>> easy add-on or gem.
>
> I totally agree with that. Should be part of the distro... Without it Ruby's
> value proposition on Windows would be "less than" that of Ruby on any other
> platform. I've found the inability to install certain gems without a
> binary-compatible compiler to be a bit like trying to brush your teeth
> without a toothbrush. Like decaffinated coffee.. or non-alcoholic beer... or
> non-adhesive tape...
>
> Seriously... Ruby should "just work" out of the box. Even on Windows. Please
> include the DevKit!
>
Hello Bob,
While I understand your sentiment and fully share the experience you
and many others suffer, I'm not fond to bundle the DevKit into the
installer.
Bundling put us in a delicate situation, where any update of the
involved packages require a new installer release. This was one of the
things the old One-Click Installer suffered.
I had shared my personal thoughts on bundling stuff in the past, and
one more precisely in text editors area.
I understand that certain gems are not provided as binaries for
Windows developers, but tools like rake-compiler have been created to
solve that. Is not up to the developers to start using it.
There are also gems that requires more work, like 3rd party libraries
and headers. Even installing those gems requires a change in the
Windows user culture -- compile things is not for everybody.
What I'm trying is to slowly generate that culture, and imposing
things into people never generated good results. Better documentation,
Guides and developers caring, these change things.
Leonardo Valeri Manera
An admirable aim!
In the meanwhile, might I suggest that the main installer do like, for
example, LyX does with MiKTeX and ghostscript?
Which is to say, check the registry to see if its installed (or
installed but too low a version), and if not, ask the user if he wants
to download & install, with a default of yes?
This is the best solution I've seen yet for this kind of problem.
Cheers,
Leo
Luis Lavena
<l.valer...@gmail.com> wrote:
>
> An admirable aim!
>
> In the meanwhile, might I suggest that the main installer do like, for
> example, LyX does with MiKTeX and ghostscript?
>
> Which is to say, check the registry to see if its installed (or
> installed but too low a version), and if not, ask the user if he wants
> to download & install, with a default of yes?
>
> This is the best solution I've seen yet for this kind of problem.
>
I would suggest we get the planned DevKit working and out (the one
that detects installed Ruby), then we can start looking on how to
improve the RubyInstaller 'install' process to advertise, detect or
something.
As Ruby, I would love to have a choice on how do things.
Robert Calco
On Thu, Aug 19, 2010 at 9:08 AM, Robert Calco <bobc...@gmail.com> wrote:Hello Bob,
>
> 2010/8/19 Dušan Majkić <dma...@gmail.com>
>>
>> > What do you guys think?
>>
>> Devkit completly changed my ruby experience on the windows platform.
>>
>> It should be made available as default with rubyinstaller, or as an
>> easy add-on or gem.
>
> I totally agree with that. Should be part of the distro... Without it Ruby's
> value proposition on Windows would be "less than" that of Ruby on any other
> platform. I've found the inability to install certain gems without a
> binary-compatible compiler to be a bit like trying to brush your teeth
> without a toothbrush. Like decaffinated coffee.. or non-alcoholic beer... or
> non-adhesive tape...
>
> Seriously... Ruby should "just work" out of the box. Even on Windows. Please
> include the DevKit!
>
While I understand your sentiment and fully share the experience you
and many others suffer, I'm not fond to bundle the DevKit into the
installer.
Bundling put us in a delicate situation, where any update of the
involved packages require a new installer release. This was one of the
things the old One-Click Installer suffered.
I hear ya.
At the end of the day as long as it's easy and intuitive to get it installed quickly and correctly, that's all that matters.
But I for one would never "not want" the DevKit installed so I would prefer if that was not something that took two clicks when one click might do. ;)
I understand your points though, and would like to thank you and others working on this to get the Ruby One-Click installed to the current state, which is better than it's ever been for Ruby coders who have to work on or deploy to Windows.
:)
- Bob
I had shared my personal thoughts on bundling stuff in the past, and
one more precisely in text editors area.
I understand that certain gems are not provided as binaries for
Windows developers, but tools like rake-compiler have been created to
solve that. Is not up to the developers to start using it.
There are also gems that requires more work, like 3rd party libraries
and headers. Even installing those gems requires a change in the
Windows user culture -- compile things is not for everybody.
What I'm trying is to slowly generate that culture, and imposing
things into people never generated good results. Better documentation,
Guides and developers caring, these change things.
--
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
--
Jon
> > example, LyX does with MiKTeX and ghostscript?
> >
> > Which is to say, check the registry to see if its installed (or
> > installed but too low a version), and if not, ask the user if he wants
> > to download & install, with a default of yes?
> >
> > This is the best solution I've seen yet for this kind of problem.
> >
>
> I would suggest we get the planned DevKit working and out (the one
> that detects installed Ruby), then we can start looking on how to
> improve the RubyInstaller 'install' process to advertise, detect or
> something.
@Leo, @Bob,
Check out the installer for http://pidgin.im/ and tell us what you think of how they handle downloading-GTK-as-part-of-the-install process, both from a technical perspective (support issues, etc?) and as end-users.
Notice where they put the Gtk runtime and what they put in the registry for the "Add or Remove Programs" dialog.
Also, if either of you have the interest I'd love to see you fork our repo and whip up a branch with Inno installer tweaks for us to look at for updates to the existing installer.
Jon
Leonardo Valeri Manera
>> > In the meanwhile, might I suggest that the main installer do like, for
>> > example, LyX does with MiKTeX and ghostscript?
>> >
>> > Which is to say, check the registry to see if its installed (or
>> > installed but too low a version), and if not, ask the user if he wants
>> > to download & install, with a default of yes?
>> >
>> > This is the best solution I've seen yet for this kind of problem.
>> >
>>
>> I would suggest we get the planned DevKit working and out (the one
>> that detects installed Ruby), then we can start looking on how to
>> improve the RubyInstaller 'install' process to advertise, detect or
>> something.
>
> @Leo, @Bob,
>
> Check out the installer for http://pidgin.im/ and tell us what you think of how they handle downloading-GTK-as-part-of-the-install process, both from a technical perspective (support issues, etc?) and as end-users.
>
> Notice where they put the Gtk runtime and what they put in the registry for the "Add or Remove Programs" dialog.
Pidgin has recently changed their process - they used to install GTK
as a separate package if you didn't have it - now by default they
install a local copy in INSTALLDIR\Gtk.
This was arguably a good idea for them, insofar as since they're not
the only users of GTK in a system, potentially, now they're not
getting bug reports due to the system GTK being a version that doesn't
work well with pidgin. It also handily frees them from having to
support all versions of Gtk which might conceivably be installed by,
say, old versions of WinGimp.
Its a little different for the DevKit, in that since its only supposed
to be used through the DevKit gems hook, and you're also the provider
of the devkit, insomuch as anyone is ever the provider of an OSS
package, you don't need such totalitarian control over the
installation of it.
The RubyInstaller should (and yes, once 1.9.2 and the new devkit kinks
have been worked out to your satisfaction, not now) check during
install for presence of devkit.
If its not present, it should check the tickmark that causes the
installer to download and install it. The default location of such an
install can be discusses when that bridge is crossed but given how
much msys likes spaces I suspect something like
C:\RubyDevKit\<version> is preferable. Pretty much everything else
unix-derived that's a developer tool does the same, ActivePerl
defaults to C:\Perl, etc.
If its present, but the version is < required version, it should offer
to upgrade it, with an option for parallel installation (visibly mark
that as "for advanced users", as anyone who actually needs 2 different
devkit versions presumably knows what they're doing). Upgrading in
this case would mean calling uninstall on the older version(s) before
installing the new one.
If its present and recent enough, uncheck the option to install, and
possibly auto-install the hook for it into the newly-installed ruby.
Given the platform we're working on I think that's the best solution possible.
This is not to say that having each copy of rubyinstaller keep its own
DevKit, but I don't think it would noticeably decrease support
problems over a managed external solution as detailed above. I'm also
a little iffy about duplicating a 70mb+ package for each ruby install
- some of us run SSDs :)
Cheers,
Leo
Jon
> to be used through the DevKit gems hook, and you're also the provider
> of the devkit, insomuch as anyone is ever the provider of an OSS
> package, you don't need such totalitarian control over the
> installation of it.
Indeed. I think we want the DevKit to be accessible by all installed Rubies rather than a private version like Pidgin. I do like how they download and extract the Gtk zip rather than embedding it in the installer.
Note that in addition to the gems pre_install hook, the DevKit can be brought into your development work via "ruby -rdevkit extconf.rb".
> This is not to say that having each copy of rubyinstaller keep its own
> DevKit, but I don't think it would noticeably decrease support
> problems over a managed external solution as detailed above. I'm also
> a little iffy about duplicating a 70mb+ package for each ruby install
> - some of us run SSDs :)
I also prefer a shared DevKit rather than duplicating its artifacts over the filesystem as a private prt of each RubyInstaller copy. I also _do not_ want the RubyInstaller's to grow in size by including the DevKit in each installer.
Thanks for your feedback on how you think the installer and the DevKit should behave.
Jon
Jon
>
> I'm not going to release 1.9.2-p0 installers yet, want to better
> document the switch of GCC and what DevKit should be used instead.
I just built ruby trunk (1.9.3dev 29056) with master and it looks good.
Regarding releasing the 1.9.2-p0 installer, I agree that the usage documentation at http://wiki.github.com/oneclick/rubyinstaller/development-kit needs to be finished before releasing the installer and the new DevKit.
I've been working with the JRuby folks so that new DevKit can be used with their new (unreleased) feature[1] to support native extensions such as rdiscount, curb, eventmachine, etc. While the DevKit (with helper .bat's) currently builds both their native support library and some native gems, we're still working through the issue. The good news is that any required DevKit changes appear to be isolated to DevKit's dk.rb helper install script and maybe a couple helper .bat's. The "core" MSys/MinGW/TDM parts of the DevKit that we count on for RubyInstaller installs continue to work fine as-is.
As DevKit's JRuby support is for one of their unreleased features and it's not clear how long it will take to finish polishing up, I plan to switch my priority to creating the Wiki docs in preparation for an ASAP 1.9.2-p0 and new DevKit release. I plan to release an updated DevKit with full JRuby support once the issues get resolved, but I don't think holding up 1.9.2-p0 installers and the new DevKit makes sense.
Thoughts?
Jon
[1] http://blog.headius.com/2010/07/what-jruby-c-extension-support-means-to.html