ruby-sig September 2016

ruby-sig@lists.fedoraproject.org

6 participants
9 discussions

Ruby 2.2
by Vít Ondruch 22 Sep '23

22 Sep '23

Hi everybody, Since Ruby 2.2 is going to be released during Christmas and -preview1 release is imminent (this Wednesday?), it is probably time to start looking into its packaging. So here is the updated .spec file [1] and scratch build [2], which can be finally build on all platforms. Sorry, no Copr for you, since Ruby's build fails there due to old RHEL kernel :/. What has changed from packaging point of view? Luckily, not much, but here are a few bullets which comes to my mind: * RPM 4.12 introduces new %load function, which is used to load RPM macros during RPM build. This allowed to drop my custom RPM macro [3]. On the other hand, you'll be able to build the Ruby only on F21+ (luckily, you should be able to build SRPM everywhere). * The RubyGems filesystem was not explicit enough, so there might be something accidentally packages. This is now more explicit, so we should be safer. * Ruby now ships with MiniTest and Test::Unit. The very good news is that they are installed so far as a regular gems. This means that you have to always specify them in your Gemfile, if you are using Bundler, but this is generally step in good direction. I hope that upstream will not change their mind :) Due to this change, we have new subpackages rubygem-test-unit (and rubygem-power_assert, which is now Test::Unit's dependency). No more %{_bindir}/testrb (but nobody is using it these days anyway, right? ;) * Some prevailing test failures were resolved, some others introduced, but hopefully they'll get resolved prior stable release. Generally, I'd say that not much has changed since 2.1, which is good news. Please test the packaging if you can and let me know about any issues you encountered. Also, if you have any other suggestions about Ruby packaging in general, what we could improve etc, this is probably good time to share. It seems that OpenSUSE guys are improving their packaging, so you might want to get some inspiration there [4, 5, 6] ;) Vít [1] http://pkgs.fedoraproject.org/cgit/ruby.git/log/?h=private-ruby-2.2 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=7578843 [3] http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=private-ruby-2.2&id=8… [4] https://build.opensuse.org/package/show/home:darix:ruby/ruby-common [5] https://build.opensuse.org/package/show/home:darix:ruby/ruby2.2 [6] https://github.com/openSUSE/gem2rpm/commits/master

4 19

ruby-sig FAS group and rubygems build in Copr
by Vít Ondruch 20 Apr '17

20 Apr '17

Hi everybody, You probably noticed, that there is ongoing build of all Python packages in Copr [1] and today, I was approached by Miroslav Suchý, that he'd like to do the same for rubygems. And this in turn triggered these questions: 1) Would you be interested to create ruby-sig group in FAS? We could make the group owner of some packages and in turn, the members of the group could maintain the packages, without explicitly asking for some ACLs. 2) For the Copr rebuild of rubygems, there needs to be some FAS group again. Python guys are asking for "pypi-builds-sig" group [2], hence following their lead, I'd like to ask for "rubygems-builds-sig" group (note that although I don't like the '-sig' suffix in this case, it is mandated by the infrastructure ticket template). So what are your thoughts? Vít [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [2] https://fedorahosted.org/fedora-infrastructure/ticket/5311

5 11

Ruby 2.4
by Vít Ondruch 02 Jan '17

02 Jan '17

Hi everybody, Time is running past and it is almost 6 months of development of Ruby 2.4. So I started to prepare some test build again. I am pushing all the changes into private-ruby-2.4 branch of dist-git if you are interested and here is the build of r55184: http://koji.fedoraproject.org/koji/taskinfo?taskID=14278233 One notable change is that XMLRPC library was extracted into separate gem, so rubygem-xmlrpc is now available as Ruby subpackage. Please give it a try and let me know if anything goes wrong. Vít

2 19

Re: Ruby on Rails 5.0 in Fedora 25
by Pavel Valena 30 Sep '16

30 Sep '16

Hi Glen, ----- Original Message ----- > From: "Glen Rundblom" <glen(a)rundblom.com> > To: "Vít Ondruch" <vondruch(a)redhat.com>, jaruga(a)redhat.com, pvalena(a)redhat.com, ruby-sig(a)lists.fedoraproject.org > Sent: Thursday, September 29, 2016 9:38:01 PM > Subject: Re: Ruby on Rails 5.0 in Fedora 25 > > Ah, I understand now, thank you Vit! > > I have made that change. > > Here is what I have now (in text mode instead of the HTML paste I was > doing): > > ---- > 4.1.1. Ruby on Rails 5.0 > > Developers will get support for a system-packaged Ruby on Rails of the > latest version. The update to Rails 5.0 will bring: > > * Action Cable: A new framework that seamlessly integrates WebSockets > with the rest of a Rails application. WebSockets is not a Rails-specific thing. It's a technology, so this is IMO a bit inaccurate. I'd go with ``` * Action Cable: A new framework that seamlessly integrates WebSockets in a Rails application. ``` > > * API mode: Rails applications can be created by using rails new > backend --api > > * Action Record attributes with a type on a model. > > * Exclusive use of Rails CLI over Rake. > > * Test Runner: enhanced abilities to run tests from Rails. > > * Sprockets 3 > > * Turbolinks 5 > > A helpful guide for upgrading Ruby on Rails can be found at: > http://guides.rubyonrails.org/upgrading_ruby_on_rails.html > > For more information about Ruby on Rails 5, and sources of this > information can be found at: > https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.0, > http://weblog.rubyonrails.org/2016/6/30/Rails-5-0-final/, and > http://guides.rubyonrails.org/5_0_release_notes.html. > > ---- > Overall it looks fine. Pavel Valena Associate Software Engineer Brno, Czech Republic RED HAT | TRIED. TESTED. TRUSTED. All of the airlines in the Fortune Global 500 rely on Red Hat. Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>

1 0

Re: Ruby on Rails 5.0 in Fedora 25
by Vít Ondruch 29 Sep '16

29 Sep '16

Hi Glen, just one nit: Dne 28.9.2016 v 06:13 Glen Rundblom napsal(a): > Rails CLI over Rake. This should be "Exclusive use of |rails| CLI over Rake" otherwise it does not make sense. Just to explain, a lot of stuff on command line was historically done using commands such as "rake db:migrate" or "rails new myapp" while now the same tasks are executed as "rails db:migrate" or "rails new myapp". Vít

1 0

Re: Ruby on Rails 5.0 in Fedora 25
by Vít Ondruch 27 Sep '16

27 Sep '16

Hi Glen, Several notes inline: Dne 27.9.2016 v 00:13 Glen Rundblom napsal(a): > > Thanks Vit, > > I have taken the information and made a couple changes: > > 1. I removed the line about keeping developers on Fedora because it > made me feel like we were trying to keep them from using other > distributions, it made me uncomfortable. > > 2. I made the list of features a itemized list to easily identify the > new features. > > Here is my current piece for the release notes please let me know what > you think, I welcome your feedback: > > > Ruby on Rails 5.0 > > Developers will get support for a system-packaged Ruby on Rails of the > latest version. The update to Rails 5.0 will bring: > > * > > ActionCable(A new framework that seamlessly integrates WebSockets > with the rest of a Rails application) > It should be "Action Cable" > * > > > * > > API mode (Rails applications can be created by using rails new > backend --api) > > * > > ActionRecord attributes with a type on a model, and exclusive use > of rails CLI over Rake. > Active Record should be two words and this item should be split into two bullets, the CLI is separate thing. > * > > > For more information, and to visit the sources of this information > please > visit: https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.0, http://weblog.rubyonrails.org/2016/6/30/Rails-5-0-final/, > and http://edgeguides.rubyonrails.org/5_0_release_notes.html. > I would use http://guides.rubyonrails.org/5_0_release_notes.html instead of the "edgeguides". And looking at the release notes, may be you can add also three additional bullets from the top of the page, i.e. * Test Runner * Sprockets 3 * Turbolinks 5 (I would not mention the "Ruby 2.2.2+ required" since it does not matter on Fedora that much. You have to use Ruby version which is available on the system). Also, may be you should mention http://guides.rubyonrails.org/upgrading_ruby_on_rails.html somewhere? It might be helpful to somebody, if (s)he has some RoR application based on system RoR, dunno .... Thx Vít > > On 09/26/2016 03:01 AM, Vít Ondruch wrote: >> Hi Glen, >> >> I think that the change proposal paragraph [1] describes the benefits >> the best: >> >> >> This update will keep Fedora up-to-date and will ensure that the current >> Ruby on Rails developers stay with us as they will get support for >> system-packaged Ruby on Rails of the latest version. Apart from that, >> update to Rails 5.0 will bring ActionCable (A new framework that >> seamlessly integrates WebSockets with the rest of your Rails >> application), API mode (You can create a new Rails application using >> rails new backend --api), ActionRecord attributes with a type on a >> model, and exclusive use of rails CLI over Rake. >> >> >> Is this enough? >> >> >> Vít >> >> >> [1] >> https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.0#Benefit_to_Fedora >> >> >> Dne 25.9.2016 v 05:57 Glen Rundblom napsal(a): >>> Greetings! >>> >>> I am working on the Ruby On Rails change in Fedora 25 section of the >>> release notes, and would like to ask your input on how it affects >>> Fedora 25, its benefits, importance, and anything else you feel that >>> should be included in the release notes. >>> >>> Thank you! >>> >>> -Glen >>> >>> >

1 0

Re: Ruby on Rails 5.0 in Fedora 25
by Vít Ondruch 26 Sep '16

26 Sep '16

Hi Glen, I think that the change proposal paragraph [1] describes the benefits the best: This update will keep Fedora up-to-date and will ensure that the current Ruby on Rails developers stay with us as they will get support for system-packaged Ruby on Rails of the latest version. Apart from that, update to Rails 5.0 will bring ActionCable (A new framework that seamlessly integrates WebSockets with the rest of your Rails application), API mode (You can create a new Rails application using rails new backend --api), ActionRecord attributes with a type on a model, and exclusive use of rails CLI over Rake. Is this enough? Vít [1] https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_5.0#Benefit_to_Fedora Dne 25.9.2016 v 05:57 Glen Rundblom napsal(a): > Greetings! > > I am working on the Ruby On Rails change in Fedora 25 section of the > release notes, and would like to ask your input on how it affects > Fedora 25, its benefits, importance, and anything else you feel that > should be included in the release notes. > > Thank you! > > -Glen > >

1 0

Celluloid back to Fedora
by Germano Massullo 20 Sep '16

20 Sep '16

Hi I am writing to you to let you know that rubygem-celluloid will be back again into Fedora repositories. I am actually taking care of all runtime dependencies. If you want to help me by doing some Package Reviews, here some of them https://bugzilla.redhat.com/show_bug.cgi?id=1370096 https://bugzilla.redhat.com/show_bug.cgi?id=1370135 https://bugzilla.redhat.com/show_bug.cgi?id=1370138 https://bugzilla.redhat.com/show_bug.cgi?id=1370153 https://bugzilla.redhat.com/show_bug.cgi?id=1370158 Thank you very much

4 8

Macros to modify gem dependencies
by Vít Ondruch 16 Sep '16

16 Sep '16

Hi, From time to time, it is necessary to modify the gem dependencies we ship. For example, it is good idea to remove the Mac/Windows specific dependencies from Listen gem or sometimes it is necessary to relax some gem dependency. Historically, we did that using sed or applying patches. I don't think neither is optimal solution. So lately, I was thinking about introducing macros to achieve this. I am thinking about two macros ATM and here is their implementation: ``` %global gemspec_add_runtime_dependency() \ read -d '' add_runtime_dependency_script << 'EOR' || : \ options = %w(%{*}) \ name = options.shift \ version = [options.join(' ')] \ spec = Gem::Specification.load('.%{gem_spec}') \ dep = spec.dependencies.detect { |d| d.type == :runtime && d.name == name } \ if dep \ dep.requirement.concat version \ else \ spec.add_runtime_dependency name, version \ end \ File.write '.%{gem_spec}', spec.to_ruby \ EOR\ echo "$add_runtime_dependency_script" | ruby\ %{nil} %global gemspec_remove_runtime_dependency() \ ruby \\\ -e "name = '%{1}'" \\\ -e "spec = Gem::Specification.load('.%{gem_spec}')" \\\ -e "spec.dependencies.reject! { |d| d.type == :runtime && d.name == name }" \\\ -e "File.write '.%{gem_spec}', spec.to_ruby" \ %{nil} ``` and you can use them as: ``` %gemspec_remove_runtime_dependency fog-dynect %gemspec_add_runtime_dependency fog-dynect ~> 10.0 %gemspec_add_runtime_dependency fog-dynect >= 10.1 ``` As you can see, both are using a bit different way of implementation. Let me discuss the details. The 'gemspec_remove_runtime_dependency' is using bunch of '-e' parameters to specify the code. The advantage of this approach is, that the build output log contains traces of the precise command which was used, e.g.: ``` + ruby -e 'name = '\''fog-dynect'\''' -e 'spec = Gem::Specification.load('\''./usr/share/gems/specifications/fog-1.38.0.gemspec'\'')' -e 'spec.dependencies.reject! { |d| d.type == :runtime && d.name == name }' -e 'File.write '\''./usr/share/gems/specifications/fog-1.38.0.gemspec'\'', spec.to_ruby' ``` This is helpful, but the output is not very nice and the implementation is polluted with a lot of noise. The other approach used in 'gemspec_add_runtime_dependency' puts the entire script into environment variable and then pipes it into the ruby. The log output looks like: ``` + read -d '' add_runtime_dependency_script + : + echo 'options = %w(fog-dynect >= 10.1) name = options.shift version = [options.join('\'' '\'')] spec = Gem::Specification.load('\''./usr/share/gems/specifications/fog-1.38.0.gemspec'\'') dep = spec.dependencies.detect { |d| d.type == :runtime && d.name == name } if dep dep.requirement.concat version else spec.add_runtime_dependency name, version end File.write '\''./usr/share/gems/specifications/fog-1.38.0.gemspec'\'', spec.to_ruby' + ruby ``` Is this actually useful? Of course, the script could be piped directly into ruby without the env variable magic, but the output is then reduced just to: ``` + ruby ``` which is not helpful at all (but could be improved by some hint as "adding dependency ...."). So what is you opinion on usefulness of these macros and on the implementation? What is the preferred way for you? BTW this is first draft of the macros. I am going to try second implementation, which will probably need to use a bit different syntax for macro calls, but it might replace the 3 lines usage example above with 2 lines version: ``` %gemspec_remove_runtime_dependency -n fog-dynect %gemspec_add_runtime_dependency -n fog-dynect ['~> 10.0', '>= 10.1'] ``` Please share your thoughts on this topic. Vít

3 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig September 2016