ruby-sig November 2012

ruby-sig@lists.fedoraproject.org

15 participants
10 discussions

BASH completion for Ruby
by Vít Ondruch 25 May '16

25 May '16

Hi guys, Anybody have any experience with some scripts for bash completion? Have you tried any? Should we integrate any? Just a quick googling gave me two results: https://github.com/mernen/completion-ruby https://github.com/pdkl95/rubygems-completion And there are probably others. I did not tried them yet. Have you? Do you have other/better tips? Thank you Vit

2 3

warning: rspec.rb provided by rubygem-rspec
by Mo Morsi 19 Feb '13

19 Feb '13

rspec1 shipped rspec.rb as part of the rubygem-rspec package rspec2 shipped rspec.rb as part of rubygem-rspec-core, so to assist in that migration we left rubygem-rspec at 1.x for the time, and converted packages to depend on rspec-core. When the migration was done, we updated rubygem-rspec. rubygem-rspec was just updated in rawhide to 2.11.0 which again provides rspec.rb (which was removed from rspec-core 2.11.0). So packages just depending on rspec-core will now need to pull in rspec to be able to use rspec.rb The fix is easy enough, just a word of warning if you see related errs in broken builds w/ gem packages starting in rawhide. rspec also depends on an updated version of diff-lcs, which is available in rawhide (thanks mamoru & vit!) -Mo

2 1

JRuby masterplan for F19 - RFC
by Bohuslav Kabrda 08 Jan '13

08 Jan '13

Hi all, as F19 is slowly approaching, I thought it'd be great to finalize the stuff about JRuby/Ruby integration with Fedora. Here are the changes and additions around JRuby, that I suggest: * Global changes - As already mentioned in [1], change the default operating_system.rb, the current version is at [2]. The question here is, whether to use versioned directories for extensions. In my opinion we should do that, as users installing Gems under /usr/local may want to install them for different version of JRuby (Rubinius in the future). This change will cost us nothing and will make sure that we can utilize this in the future. - Add additional macros to macros.rubygems, see [3] (if the macros names seem confusing, see the section about packaging gems for JRuby below). - Two connected problems: 1) RPM generates auto provides from shebangs, e.g. #!/usr/bin/ruby will automatically require ruby package; 2) How to run programs with #!/usr/bin/ruby shebangs under JRuby? -- We've discussed this situation with Vit and we came up with an interesting proposal for solution. There will be a package (probably with just one file) /usr/bin/ruby. This will be a bash script, that will take all given parameters and pass them to the proper interpreter (/usr/bin/ruby-mri or /usr/bin/jruby). There will be a default choice (MRI, I guess) and the switching will be done by passing _jruby_ (possibly also containing version) or _mri_ as the first parameter. If e.g. /usr/bin/ruby-mri is not found, the script will automatically try /usr/bin/jruby and if that is not present either, it will print out that user needs to install a Ruby runtime. -- This way, the automatically generated requires will point to the package containing /usr/bin/ruby and not the actual ruby package, therefore leaving it up to user which Ruby runtime he wants to install. -- Also, every executable file with this shebang can be run with _mri_ or _jruby_ parameter: "rspec _mri_" vs. "rspec _jruby_", the same for gem, irb and anything that has the proper shebang. * Changes to packaging - Platform independent packages mustn't R: ruby, unless there is a specific reason to do so. - Packages with MRI binary extensions will have to R: and BR: ruby explictly, not just ruby(abi), as that will also be provided by JRuby. - Packages meant only for JRuby will have to R: and BR: jruby explictly (same reason). These will use the %gem_extdir_jruby macro. - Packages with extensions for both Ruby and JRuby (let's consider rubygem-json, example of converted specfile is at [4]): -- MRI extension will probably stay in the core package (rubygem-json). -- There will be a subpackage with -java suffix (because the naming scheme on rubygems.org gives e.g. json-1.7.5-java). The subpackage will contain it's own .gemspec and because all the directory/file names contain the "-java" string, it will use the %gem_*_java macros. -- The -java subpackage will contain the JRuby extension under %gem_extdir_java and it's platform independent part will be a symlink to platform independent part of its MRI counterpart (e.g. /usr/share/gems/gems/json-1.7.5-java -> /usr/share/gems/gems/json-1.7.5). -- The disadvantage of this approach is, that the core package (rubygem-json) will be a dependency of rubygem-json-java, therefore forcing MRI to be installed. or -- The rubygem-json-java package could be independent of rubygem-json (e.g. everything same as above, except it will actually contain the platform independent part). This would in fact not require MRI ruby to be installed, but I'm not sure of the consequences of this. -- A big question is, how to handle provides (applies to both cases). RPM cannot say "I'm fine with rubygem-json or rubygem-json-java", so the -json package will probably have to Provides: rubygem(json-java) and users will have to install these manually, if they want to use JRuby. * Others: - There is also a general problem with Provides/Requires of the interpreters themselves. I think that JRuby should provide both ruby(abi) = 1.9.1 and ruby(abi) = 1.8. I'm however not sure whether to provide e.g. rubygem(io-console), which is required by rubygems package. The problem with this provide is this: 1) user installs JRuby (that provides rubygem(io-console)) and rubygems. 2) user installs MRI, rubygem-io-console doesn't get installed, as the dependency is already satisfied. 3) "gem" command (specifically its part that depends on io-console) run under MRI fails. As I see it, we probably won't get rid of having MRI ruby installed with JRuby, at least not for the near future (but at least the auto-requires of /usr/bin/ruby can be handled, which is a step in the right direction). I hope I made my points clear, please share your thoughts/comments/critisism. BTW, I'll be updating my testing repo with JRuby as soon as JRuby 1.7.1 are out. When we agree on how the stuff mentioned above should work and have it approved by FESCo/FPC, I'll start pushing JRuby into F19, but that seems to be far away for now... Thumbs up if you read the whole mail :) Slavek. -- Regards, Bohuslav "Slavek" Kabrda. [1] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-November/001142.html [2] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/operating_system… [3] https://github.com/bkabrda/jruby.spec/blob/master/rubygems/rubygems.spec#L1… [4] https://github.com/bkabrda/jruby.spec/blob/master/rubygem-json/rubygem-json…

6 20

My Documentation for the Ruby Stack on Fedora
by Animesh Tripathi 18 Dec '12

18 Dec '12

Hi, I'm Animesh, a 16 year old high school student from New Delhi, India. I'm participating in the Google Code-In 2012 contest, and as part of a task, I created a video documenting the process of installing Ruby on Rails using the Ruby Stack on Fedora, and then setting up a simple application along with a database, and finally printing a string from the database. Here's the YouTube link to the screencast: http://www.youtube.com/watch?v=x0mD2-rvScA Here's the PDF Guide I made which documents each command from the video: https://dl.dropbox.com/u/70893849/Fedora%20Rails%20Stack%20Guide.pdf I hope you enjoy my first contribution to the Ruby SIG as much as I enjoyed making it! Thanks Animesh Tripathi

3 2

Logos and Mission Statement for the Ruby-SIG
by Mark Klein 11 Dec '12

11 Dec '12

Hello, I'm Mark Klein, a 14 year old high school student from Honolulu, Hawaii. I'm participating in the Google Code-In contest for 2012 and for my task, I designed two logos and wrote a mission statement for the Fedora/Ruby SIG. Here's the link to the two logos: http://www.google-melange.com/gci/work/download/google/gci2012/8007231?id=2… http://www.google-melange.com/gci/work/download/google/gci2012/8007231?id=3… This is the mission statement: The goal of the Fedora/Ruby Special Interest Group is to become the defacto-platform for ruby development. This is being achieved with our stack incorporating security fixes and new features while complying with both Ruby and Fedora standards. I hope you like my contribution to the Fedora/Ruby SIG! Thank you, Mark Klein

11 12

Ruby 2.0
by Vít Ondruch 05 Dec '12

05 Dec '12

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-2…

1 3

RubyGems changes to accomodate multiple ruby implementations
by Bohuslav Kabrda 29 Nov '12

29 Nov '12

Hi all, as I'm working towards getting JRuby packaged, I started playing around with RubyGems and the default operating_system.rb, that modifies the behaviour on Fedora. Since the ultimate plan is to have shared RubyGems for all implementations, every one of these implementations will need its own extension directories. So far, we had just MRI and its extensions went under /usr/lib[64]/gems/exts. I'd like to propose that we change this to /usr/lib[64]/gems/ruby for MRI, /usr/share/gems/jruby for jruby (since java extensions aren't platform specific) and when rubinius comes, we can place its extensions under /usr/lib[64]/gems/rubinius. The customized operating_system.rb (and the whole rubygems) are at [1]. I would appreciate any comments/thoughts on this. There is a small regression hidden in this: The gems installed with "sudo gem install" currently place their extensions under /usr/local/lib64/gems/exts, which would also change to /usr/local/lib64/gems/ruby, causing these gems to need reinstallation if my changes are applied, but I don't think this should keep us from doing this transition. Thoughts? Thanks, Slavek. -- Regards, Bohuslav "Slavek" Kabrda. [1] https://github.com/bkabrda/jruby.spec/tree/master/rubygems

4 4

updating gems
by Mo Morsi 29 Nov '12

29 Nov '12

Before jumping back into isitfedoraruby, I plan on pushing some long overdue updates to some of the gems I maintain. The following are on my list: Must update: - childprocess: 0.2.0 -> 0.3.6 (BZ #873320, required for rubygem-aruba update) Upstream release monitoring - minitest: 2.10.1 -> 4.2.0 (BZ #798247) - ruby2ruby: 1.2.4 -> 2.0.1 (BZ #843895) - ruby_parser: 2.0.4 -> 3.0.1 (BZ #843896, could we use this gem in gem2rpm?) - sexp_processor: 3.0.4 -> 4.1.2 (BZ #843897) - ZenTest: 4.6.2 -> 4.8.2 (BZ #828262) - sass: 3.1.20 -> 3.2.2 (BZ #847675) - thor: 0.14.6 -> 0.16.0 (BZ #843898) --- the following are only point releases so I don't expect any major problems w/ these: - webmock: 1.8.7 -> 1.8.11 (BZ #842655) - haml: 3.1.6 -> 3.1.7 (BZ #847670) - treetop: 1.4.11 -> 1.4.12 (BZ #871769) - oauth: 0.4.4 -> 0.4.7 (BZ #746468) - uuidtools: 2.1.2 -> 2.1.3 (BZ #840762) - yard: 0.8.2 -> 0.8.3 (BZ #866401) --- Others: - authlogic: 3.0.3 -> 3.1.3 - compass: 0.11.5 -> 0.12.2 - cucumber: 1.1.9 -> 1.2.1 - vcr: 1.10.0 -> 2.3.0 --------------------------------- Unless there are any objections, I would like to start pushing updates to rawhide soon (rawhide only). To assist in the update process, I've whipped up a little script (which you can find here [1]) called the Gem Rpm Updater, or gru.rb This script simply wraps some of the fedpkg commands to checkout a gem from Fedora, download the latest version from rubygems, and updates the spec file / builds it via koji. It automates everything up to the git push and official koji build / tagging. Most likely it won't catch all edge-cases, and some intervention will be needed, but it spits out any discrepancies in the process if it notices them, and I'm hoping if we standardize our workflow enough, this will work w/out intervention for most packages (perhaps we could offer another level of compliance in or ontop of Fedora's Ruby guidelines). I was able to come up with this over the course of a few hours, but if there is an interest in it, it could be expanded to handle more of the process. A next logical step could be to integrate David's ruby wrappers to the Fedora package API [2] to try to match dependencies from rubygem and fedora in an elegant manner. Thoughts? -Mo [1] https://gist.github.com/4036394 [2] https://github.com/daviddavis/pkgwat

4 8

gem-nice-install
by Vít Ondruch 12 Nov '12

12 Nov '12

Hi, Today, I have released gem-nice-install RubyGems plugin, which helps you to install binary gems on your Fedora/RHEL. Any feedback welcome, as well as opinion, if we should integrate this plugin on Fedora by default. Vit

5 9

undeprecating rubygem-{bunny,moneta,ohai}
by Julian C. Dunn 05 Nov '12

05 Nov '12

Hi, Mo Morsi pointed me over here from -devel. I'm working on packaging Opscode Chef for Fedora and EPEL 6 (EPEL 5 is too old to do this sanely) The first step for me is to un-deprecate the above packages. I have specfiles ready to go, except I have one question about "Requires: ruby(abi) = XXX". What should the correct value be, given that I want to support EPEL 6 (has Ruby 1.8) and current Fedoras (have Ruby 1.9)? Is it acceptable to wrap this in a conditional, example: %if %{?el6} Requires: ruby(abi) = 1.8 %else Requires: ruby(abi) = 1.9.1 %endif or not? - Julian

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig November 2012