ruby-sig December 2012

ruby-sig@lists.fedoraproject.org

14 participants
14 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 18 Feb '13

18 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

Rubygem RPMs and "bundle install"
by Philip Rhoades 08 Jan '13

08 Jan '13

People, I have just upgraded to Fedora 18 x86_64 and installed all the Ruby/Rails RPMs but I notice when I create a test rails app and then add something to Gemfile and do "bundle install", the system starts pulling in all the native Gems - I would like to stick to just using RPMs - so is there a changed procedure for the RPM environment? Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: phil(a)pricom.com.au

2 1

isitfedoraruby updates
by Mo Morsi 22 Dec '12

22 Dec '12

Tons of updates to the http://isitfedoraruby.com webapp! Much appreciation goes out to Nico, Mark, Animesh, and Kendhia (all cc'd) who have all added all of the following features recently. In no particular order: - Now hosted on Openshift!!! - Integrated it w/ jenkins so whenever we push to the 'stable' branch in git, the openshift instance gets automatically updated. (meaning quicker updates) - Began visualizations, for example see the packages a fedora user maintains in bubbles whose size is proportional to the number of commits in git: http://www.isitfedoraruby.com/stats/vondruch/user_rpms - Now has a timeline of all gem / rpm activity (from both upstream and on the fedora side) http://www.isitfedoraruby.com/stats/rubygem-activesupport/timeline - Began gamification: added code to import the fedora user maintaining the package and are starting to display this info in various ways, such as with badges: http://www.isitfedoraruby.com/fedorarpms/mmorsi/badge - Static content and better styling, some of the blank pages are now flushed out - Started adding i18n support for internationalized text - Added better error pages for http 404, 500, etc Of course the app is still in development so if you want to see anything just shout out or send a pull request! -Mo

2 1

purpose of ruby(abi), python(abi), etc
by Vít Ondruch 20 Dec '12

20 Dec '12

Hi, Can somebody enlighten me, what is the purpose of ruby(abi) (replace by python(abi) if you wish) virtual provide? Especially, why Ruby packaging guidelines mandate "Requires: ruby(abi) = 1.9.1", i.e. versioned require? And why in Python packages, python(abi) is automatically generated? If the package is noarch, there is very high chance, that it would work with Ruby 1.8 as good as with Ruby 1.9 or even Ruby 2.0. If the package is arch dependent, it has automatically generated dependency on libruby.so.1.9. So there is no chance to install it or run it with other version of Ruby. Now why I am asking? We would like to have in F19 Ruby 2.0 accompanied by JRuby 1.7 and in the future, we would love to see these interpreters interchangeable, i.e. it doesn't matter which interpreter is on your system, since it will be able to run the gem/application shipped in Fedora. However, while Ruby 2.0 should provide "ruby(abi) = 2.0", JRuby are not yet fully 2.0 ready, so they should not provide "ruby(abi) = 2.0". Moreover, the term ABI with JRuby is a bit misleading. So how we can make every noarch ruby package compatible with both interpreters in terms of requires? One possibility would be to drop the abi version unless it is explicitly needed. However, it renders ruby(abi) as not the best virtual provide name for this goal. Any ideas? Vít

2 1

Ruby 2.0 in F19
by Vít Ondruch 20 Dec '12

20 Dec '12

Hi everybody, According to Ruby 2.0 release schedule: - code freeze: 23 Dec. - 2.0.0-rc1 release: 1W Jan. (expected) - 2.0.0-rc2 release: 1W Feb. (expected) - 2.0.0-p0 release: 24 Feb. the official release date is quickly approaching. Therefore, I would like to update you about current plans for Fedora * I am trying to closely track recent development of Ruby 2.0 and the .spec is available in ruby-2.0 branch of dist-git repo [1]. * I started to put together pieces of feature proposal for Ruby 2.0 in F19 [2]. * Every package which depends on Ruby will need to be rebuild. There are several reasons: - The Ruby 2.0 is ABI incompatible with Ruby 1.9.3 (although it should be source level compatible). - Due to better integration of JRuby into Fedora [3], we would like to take this opportunity to restructure RubyGems folder layout. This should allow us to support Rubinius in the future as well. - I would like to get rid of ruby(abi) virtual provide, since it does not express enough the level of compatibility between JRuby and MRI. There is ongoing discussion about it on packaging list [4]. So at the beginning of January, I'd like to ask rel-eng for dedicated build target for rebuild of Ruby packages (we will probably use this target for JRuby build as well). Please let me know if you want to opt-out and rebuild your packages by yourself. Vít [1] http://pkgs.fedoraproject.org/cgit/ruby.git/tree/?id=ruby-2.0 [2] https://fedoraproject.org/wiki/Features/Ruby_2.0.0 [3] http://fedoraproject.org/wiki/Features/JRuby_1.7.1 [4] http://lists.fedoraproject.org/pipermail/packaging/2012-December/008798.html

1 0

Hello SIG!
by Nicolás Satragno 19 Dec '12

19 Dec '12

Hi guys! My name is Nicolás Satragno and I'm a Google Code-In student with a special interest in coding who found Ruby *the* programming language. I'm currently working to improve the Fedora Ruby site [1]. Some of the enhancements I already made include migrating the site to OpenShift, bugfixing and starting a gamification process to raise interest in packaging Ruby gems. There's a lot to do to make Fedora the best Ruby platform available, and I'll do whatever I can, even out of the scope of Google Code-In. So far I found the community thriving and cheerful, which is why I'm almost solely focusing on the fedoraruby project. I'm also a GNOME Spanish translator (mostly localizing programming tutorials/reference) and member of the GNOME foundation. My current task is internationalizing the fedoraruby web application. Sounds interesting? Fork the github project [2] and get involved! Happy hacking. [1] http://www.isitfedoraruby.com [2] https://github.com/zuhao/isitfedoraruby -- Nicolás Satragno <nsatragno(a)gnome.org> GNOME Spanish translator

3 2

New project: Dirby
by Darryl L. Pierce 19 Dec '12

19 Dec '12

I'm the current maintainer for the rubygem-wirble package. Unfortunately, it seems that wirble has been abandoned by the developers. So I've forked the code and named it Dirby [1]. I'm inviting anybody who's interested to join me in getting it fixed up and working better for Ruby 1.9, as well as to enhance the codebase. [1] https://github.com/mcpierce/Dirby -- Darryl L. Pierce <mcpierce(a)gmail.com> http://mcpierce.multiply.com/ "What do you care what people think, Mr. Feynman?"

2 2

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

17 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig December 2012