Ruby 2.0
by Vít Ondruch
Hi,
Just for your information, I have pushed ruby-2.0 branch into the Ruby's
git repo. So if you like test the latest Ruby, you need to get the
latest HEAD tarball, which could be prepared using:
$ cd /path/to/your/ruby/sources
$ ./tool/make-snapshot tmp
Note that you have to have available subversion and bison on your
system. Also note that the content of tarball is needed to be repacked,
that the Ruby sources will be stored in "ruby-2.0.0-p0" folder (I know,
it is annoyance, but you can fix the spec and send me a patch ;). Also
note that I currently keep the ruby_abi at 1.9.1, while the official
release will have 2.0.0 probably. This should allow you to use Fedora's
gems without rebuild. Any comments/patches are appreciated.
Vit
[1]
http://pkgs.fedoraproject.org/gitweb/?p=ruby.git;a=tree;h=refs/heads/ruby...
11 years
Ruby-SIG meeting at FUDCon Paris 2012?
by Vít Ondruch
Hi Rubyists,
Since me and bkabrda are coming to FUDCon Paris, it would be nice
opportunity to meet you, other Rubyists, and discuss some topics and
future directions of Ruby in Fedora. Please let us know who would be
interested to come and share your topics, which should be discussed. I
can throw in several right now:
* JRuby and Rubinius in Fedora and their integration with RubyGems.
* Bundler?
* Rails 3(4) in Fedora.
* Redmine, Passenger?
* Parallel installation of several gem versions.
* gem2rpm improvements
Vit
11 years, 2 months
Re: JRuby 1.7 and Fedora
by Charles Oliver Nutter
Hello all!
I've copied Tom Enebo on this reply...he may want to get on the list too.
> From: "Bohuslav Kabrda" <bkabrda(a)redhat.com>
>
> Hi all,
> since we have MRI Ruby integrated pretty nicely into Fedora, I started working on JRuby's new upcoming release (1.7) - I'm planning to put it into Fedora 19.
Excellent!
> Work to do:
> Most importantly, I'd like to work on integrating JRuby's RubyGems with our system RubyGems, so that JRuby doesn't include (at least in Fedora) its own slightly modified copy. My idea (please shout if you don't like it!) is to hook JRuby into our RubyGems concept [4]:
> - All the behaviour mentioned in [4] will stay.
> - JRuby and MRI will load non-platform-specific Gems from the same locations, only the extensions will be placed in different directories.
If this is possible, I don't see an issue. JRuby currently "supports"
C extensions, but we're deprecating that...so in general the only gems
you'll get on JRuby are non-extensions (no platform specified in the
gem) and -java gems (containing compiled classes or jar files; e.g.
nokogiri, hpricot, json).
As long as you can have nokogiri-java and nokogiri C ext installed
without JRuby *ever* loading the C ext, this should be fine.
> How to achieve that:
> - Ideally push JRuby's changes to RubyGems upstream (not sure if they'd accept them), or just apply them to our Fedora RubyGems downstream for the time being - shouldn't break anything, AFAICS
We have a standing bug to get all of our changes pushed upstream. Most
of them are just one-off patches, but there's also our maven support
(which, I'm sad to say, never really worked like we wanted it to).
Ideally we could ship stock RubyGems for JRuby 1.7 final.
> - Make JRuby work with our custom operating_system.rb [5] - this would probably require the JRuby's RbConfig::CONFIG to somehow change it's values closer to MRI's
File an issue and we can look into it. We largely simulate RbConfig
since we don't actually have a per-platform build time to populate it.
> - Figure out the packaging changes around it:
> -- Naming Gems that are only for JRuby
Any gem that's -java platform will only work on JRuby. There may be
non -java platform gems that use JRuby-specific features (like Java
integration) too, however.
> -- Placement of JRuby's extensions
> -- Creating packages for Gems that have extensions for both JRuby and MRI
> -- How to work with ruby(abi) virtual provides - both implementations should have them, but yum currently resolves virtual provides "randomly" (it chooses the provider that has less dependencies, if I'm correct)
So this is basically allowing JRuby to "provide" "ruby" as a
dependency, right? Yeah ideally we should be able to do that, but of
course the C extension thing makes it hard for us to replace them
everywhere (and the Java extension thing makes it hard for them to
replace us everywhere.
> I'm cc'ing Charles Nutter in hope that he will join this discussion on ruby-sig :)
I'm on the list now :)
FYI, the JRuby 1.7 schedule has us doing a final release around the
end of this month. Ideally we'd have everything we need changed
wrapped up ASAP.
- Charlie
11 years, 2 months
JRuby 1.7 and Fedora
by Bohuslav Kabrda
Hi all,
since we have MRI Ruby integrated pretty nicely into Fedora, I started working on JRuby's new upcoming release (1.7) - I'm planning to put it into Fedora 19.
Work already done:
So far, I have updated JRuby's dependencies (in my private repository, none of that has reached Rawhide yet) and made JRuby build and pass tests with Fedora's java libraries.
You can find my work at these places:
[1] - Source RPMs of JRuby and all updated dependencies
[2] - A yum repo to use with F19 (you'll probably just want to add it to a mock config for the time being)
[3] - A github repo with jruby.spec and Fedora specific patches - the spec still has some TODOs, but works. I accept pull requests :)
Work to do:
Most importantly, I'd like to work on integrating JRuby's RubyGems with our system RubyGems, so that JRuby doesn't include (at least in Fedora) its own slightly modified copy. My idea (please shout if you don't like it!) is to hook JRuby into our RubyGems concept [4]:
- All the behaviour mentioned in [4] will stay.
- JRuby and MRI will load non-platform-specific Gems from the same locations, only the extensions will be placed in different directories.
How to achieve that:
- Ideally push JRuby's changes to RubyGems upstream (not sure if they'd accept them), or just apply them to our Fedora RubyGems downstream for the time being - shouldn't break anything, AFAICS
- Make JRuby work with our custom operating_system.rb [5] - this would probably require the JRuby's RbConfig::CONFIG to somehow change it's values closer to MRI's
- Figure out the packaging changes around it:
-- Naming Gems that are only for JRuby
-- Placement of JRuby's extensions
-- Creating packages for Gems that have extensions for both JRuby and MRI
-- How to work with ruby(abi) virtual provides - both implementations should have them, but yum currently resolves virtual provides "randomly" (it chooses the provider that has less dependencies, if I'm correct)
I'm cc'ing Charles Nutter in hope that he will join this discussion on ruby-sig :)
If you have any other ideas or you would do something differently, now is the best time to discuss that.
Thanks all,
Slavek.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] http://bkabrda.fedorapeople.org/jruby/srpms/
[2] http://bkabrda.fedorapeople.org/jruby/jruby.repo
[3] https://github.com/bkabrda/jruby.spec
[4] http://bkabrda.fedorapeople.org/fedora17-ruby-eng-v2.pdf
[5] http://pkgs.fedoraproject.org/cgit/rubygems.git/tree/operating_system.rb
11 years, 2 months
