ruby-sig September 2011

ruby-sig@lists.fedoraproject.org

13 participants
9 discussions

Migration from RSpec 1.3 to RSpec 2.x
by Vít Ondruch 27 Feb '12

27 Feb '12

Hi guys, Since February, there are available RSpec 2.x in Fedora repositories. However, as of now, the main package rubygem-rspec was not migrated to RSpec 2.x and still provides RSpec 1.3 functionality. It would be nice, if we could finish the migration to RSpec 2.x lets say in F17 time frame. What are your opinions? The list of packages which depends on RSpec 1.3 is attached bellow. If you wonder how to use RSpec 2.x for your package, it is usually quite easy. In you spec just replace BuildRequires: rubygem(rspec) with # Use rspec-core until rspec are migrated to RSpec 2.x BuildRequires: rubygem(rspec-core) and in you %check section, if you are not using Rake, replace call to 'spec' with 'rspec'. As an example, you can take a look on one of mine rubygems, e.g. rubygem-regin, rubygem-pg. Once we will migrate all packages into RSpec 2.x, we can migrate also the rubygem-rspec and change the BR back to rubygem(rspec). Vit -------- Pu*vodní zpráva -------- Pr(edme(t: Re: aeolus conductor / rails 3 / F16 integration path Datum: Tue, 12 Jul 2011 10:47:36 -0400 Od: Mo Morsi <mmorsi(a)redhat.com> Komu: Vít Ondruch <vondruch(a)redhat.com> > It is currently 24 packages which are using RSpec 1.x: > > ]$ repoquery --repoid=fedora-source --arch=src --whatrequires > 'rubygem(rspec)' > rubygem-bcrypt-ruby-0:2.1.2-2.fc15.src (mmorsi) > rubygem-boxgrinder-build-0:0.9.1-1.fc15.src (goldmann) > rubygem-boxgrinder-core-0:0.3.1-1.fc15.src (goldmann) > rubygem-commander-0:4.0.3-4.fc15.src (mfojtik) > rubygem-cucumber-0:0.10.0-5.fc15.src (mmorsi, clalance, mfojtik) > rubygem-cucumber-rails-0:0.3.2-5.fc15.src (mmorsi, clalance, mfojtik) > rubygem-facon-0:0.4.1-2.fc15.src (stahnma) > rubygem-factory_girl-0:1.3.2-3.fc15.src (mfojtik) > rubygem-ffi-0:0.6.3-2.fc15.src (bkearney) > rubygem-linode-0:0.6.2-1.fc15.src (stahnma) > rubygem-mail-0:2.2.15-2.fc15.src - upstream at 1.3.x (vondruch) > rubygem-multimap-0:1.1.2-3.fc15.src - upstream at 1.3.x (mmorsi) > rubygem-mustache-0:0.11.2-5.fc15.src - doesn't use RSpec at all. Seems to be wrong dependency (vondruch) > rubygem-rack-test-0:0.5.4-1.fc15.src (mfojtik) > rubygem-rake-compiler-0:0.7.8-1.fc15.src (mamoru) > rubygem-regin-0:0.3.7-3.fc15.src - upstream at 2.x (vondruch) > rubygem-rerun-0:0.5.2-4.fc15.src (mfojtik) > rubygem-scruffy-0:0.2.6-2.fc15.src (mmorsi) > rubygem-simple-navigation-0:3.0.0-3.fc15.src (mfojtik) > rubygem-thin-0:1.2.7-2.fc15.src (mfojtik) > rubygem-typhoeus-0:0.2.0-2.fc15.src (mfojtik) > rubygem-uuidtools-0:2.1.1-1.fc14.src (mmorsi) > rubygem-warden-0:1.0.3-4.fc15.src - upstream at 2.x (vondruch) > rubygem-yard-0:0.5.3-3.fc14.src (mmorsi) > > So from my packages, 2 can be converted into RSpec 2.x right now, 2 are > using 1.3, so it would need some effort and 1 seems to be just wrong > dependency. May be we should move this discussion into ruby-sig ML I appended the package owners onto the list for future reference. Agree on moving this conversation to ruby-sig.

8 42

Re: Migration from RSpec 1.3 to RSpec 2.x
by Shawn Starr 10 Feb '12

10 Feb '12

Im about to submit whole bunch of rubygems to Fedora. Most of them use rspec 1.3. On Mon Jul 25th, 2011 10:10 AM EDT Mo Morsi wrote: >Since this list is a lot shorter than the corresponding list in Fedora, >perhaps we can get these package maintainers to update to RSpec 2. > >Otherwise, perhaps we can leave it in there as there for now, push the >rspec-core and other subcomponents to EPEL, and update the BoxGrinder >RPM to depend on those subcomponents instead of rspec itself? > > -Mo > >On 07/22/2011 09:18 AM, Marek Goldmann wrote: >> For EPEL 6 - exactly 5: >> >> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)' >> rubygem-extlib-0:0.9.13-5.el6.src >> rubygem-facon-0:0.4.1-2.el6.src >> rubygem-rack-test-0:0.5.4-1.el6.src >> rubygem-thin-0:1.2.8-4.el6.src >> rubygem-uuidtools-0:2.1.1-1.el6.src >> >> For EPEL 5 - also 5: >> >> $ repoquery --repoid=epel-source --arch=src --whatrequires 'rubygem(rspec)' >> rubygem-extlib-0:0.9.13-5.el5.src >> rubygem-facon-0:0.4.1-2.el5.src >> rubygem-linode-0:0.6.2-1.el5.src >> rubygem-thin-0:1.2.8-2.el5.src >> rubygem-uuidtools-0:2.1.1-2.el5.src >> >> --Marek >> >> On 22 lip 2011, at 09:48, Vít Ondruch wrote: >> >>> RSpec 2 as they are in F16 can be imported into EPEL right now. Any idea >>> how many packages depends on RSpec in EPEL? >>> >>> >>> Vit >>> >>> >>> >>> Dne 21.7.2011 20:49, Marek Goldmann napsal(a): >>>> There is one more thing: >>>> >>>> Now I upgraded to RSpec 2 in Fedora. I plan to submit BoxGrinder to EPEL 6, but there is only RSpec 1.3. What would be the approach to bump RSpec there? >>>> >>>> --Marek >>>> >>>> On 18 lip 2011, at 18:49, Mo Morsi wrote: >>>> >>>>> Perhaps we can shoot for doing this w/ F17, and if we are unable to >>>>> migrate all the dependent packages over, then add a rspec1 compat >>>>> package to buy us some more time. >>>>> >>>>> In any case, would rather push this off to F17 myself as a few of us are >>>>> going through and updating alot of the rails related plugins to be >>>>> compatible w/ Rails 3 in Fedora. We're trying to get this done by the >>>>> F16 deadline next week. >>>> --Marek >>>> >>>> _______________________________________________ >>>> ruby-sig mailing list >>>> ruby-sig(a)lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig >>> >>> _______________________________________________ >>> ruby-sig mailing list >>> ruby-sig(a)lists.fedoraproject.org >>> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig >> >> _______________________________________________ >> ruby-sig mailing list >> ruby-sig(a)lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig > >_______________________________________________ >ruby-sig mailing list >ruby-sig(a)lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

4 19

Review Request & Need Sponsor: Ruby 2.3.12 in Fedora 15+
by Emanuel Rietveld 30 Nov '11

30 Nov '11

See https://bugzilla.redhat.com/show_bug.cgi?id=726690 Although Rails 3 was released, there are still rails projects working with rails 2.3 series. Rails 3 is not backwards compatible and some key features are not yet working in Rails 3. One notable project still on rails 2.3 is the issue tracker redmine http://www.redmine.org Since rails 2 and rails 3 are perfectly parallel installable, I would like to maintain rails 2.3 series in Fedora until it really becomes obsolete. Therefore I have packaged Ruby 2.3.12 for F15/F16, basing them on the Rails 2.3.8 packages already in F14. This is my first package for Fedora and I welcome any feedback. Thank you for your time. -Emanuel ---------- Forwarded message ---------- From: Mo Morsi <mo(a)morsi.org> Date: Tue, Aug 2, 2011 at 9:24 PM Subject: Re: Rails 2 in F16 To: Emanuel Rietveld <codehotter(a)gmail.com> Hey Emanuel, appreciate the effort. Will look at it if I get the chance, but time is short nowadays so not sure when that is going to be. Most likely you will have luck if you email the ruby sig directly. http://lists.fedoraproject.org/pipermail/ruby-sig/ Since you are a new packager though, you will have to go through the sponsorship process. Not hard, but it could take longer. Take care, -Mo

2 3

FUDCon:Milan 2011 - Ruby SIG meeting
by Vít Ondruch 03 Oct '11

03 Oct '11

Hello everybody, I'd like to bring to your attention that there was proposed by Ruby SIG meeting as part of FUDCon Milan [1]. I would like to take this meeting as change to discuss Ruby future in Fedora. Here are few point I'd like to discuss: * Ruby 1.9.3 for F17. I have already pre-prepared feature page [2] for this and I am working towards packaging Ruby 1.9.3. However, there are several issues including - How to correctly name and version subpackages such as RubyGems, RDoc, Rake, IRB - How to maintain updates of them late. - Directory structure. * Support of gems for MRI and JRuby. - Is it possible to share RubyGems? - Is it possible to share gems? * Support of multiple versions of gems on single installation, e.g. Rails 2 vs Rails 3. * Refresh of Ruby Packaging Guidelines - They do not always follow best practices - They will need to be updated because of Ruby 1.9.3 * gem2rpm future and possible extensions This is list is not exhaustive, so please feel free to add few more points, which you think might be interesting to discuss. Vit [1] https://fedoraproject.org/wiki/FUDCon:Milan_2011 [2] https://fedoraproject.org/wiki/Features/Ruby_1.9.3

11 24

Ruby 1.9.3 spec file
by Vít Ondruch 02 Oct '11

02 Oct '11

Hello, I have recently pushed my ongoing work on packaging Ruby 1.9.3 for F17 to my github [1]. Pleas don't hesitate and contact me if you have any comments. Pull requests are welcomed. Vit [1] https://github.com/voxik/ruby.spec

3 4

rubygem stomp build fails on el5
by Michael Stahnke 27 Sep '11

27 Sep '11

I'm trying to update to rubygem-stomp to 1.1.9. I was able to do this on all platforms except el5. I keep getting some type of stack overflow errors. I would appreciate any help. Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=3380379

2 1

Do we have stats on how many people use the various rubygem rpms / How can we better package rails apps?
by Tejas Dinkar 23 Sep '11

23 Sep '11

Hey all, I'm wondering if we had any stats on usage patterns for various rubygem rpms. I've been developing and deploying rails apps for a while, and here is the usage patterns that I typically see: Fact 1: The ruby world evolves (and often breaks APIs) very quickly. RSpec 1.x is totally different from RSpec 2.x. Thus, people tend to keep hard dependencies on the "~> x.y" version of a gem, which may not be what another project needs. Pattern 1: Because of the above, all developers tend to just use the 'gem' command to maintain their gem stack. Add rvm and rbenv to the mix, which most developers have adopted. Now, the question becomes the following: "What does gem provide that rpm doesn't?", and the answer I came up with is the following: * Ability to install multiple versions of a gem at the same and let bundler/3rd party choose what it needs * Compile a gem that isn't available by default Pattern 2: Some people use gem to install even on production. As you can imagine, this is frowned upon because it requires a compiler, and hard to manage native dependencies. This is considered an anti pattern. Pattern 3: What people have started doing is to do a bundle deploy --deployment, which creates a local copy of all gems. After running this on a deployment-like machine, i just tar/rpm up the whole folder, and drop it in production. AFAIK, this is considered the best practice Practical Question 1: Fedora has a policy that if x depends on y, then x and y must be packaged separately, and then both approved in the repo. Now if z also depends on y, then we have a general nightmare all round. I was wondering if it makes sense, knowing this, to package rails apps as per pattern 3, keeping a local app specific copy of all gems (given, of course, that all gems meet Fedora's license policies). I know this doesn't make that much sense for (say) Ruby-Qt apps, but at least it will help package things like redmine for fedora. Practical Question 2: Does it make sense to integrate more closely with gem? I'm not sure what i mean, i'm just tossing it out there. Is there something that we can do to get some of the benefits i mentioned in Pattern 1 in an easy way? -- Tejas Dinkar C42 Engineering

2 1

Test runs by itself, fails when run with everything...
by Darryl L. Pierce 09 Sep '11

09 Sep '11

I have a unit test that is failing to run under Rake when it runs with all unit tests. But if I run it by itself using either "rake test TEST=path/to/file" or else run it with ruby using "ruby path/to/file" it passes every time. The failure is caused by the setup method not being invoked before each test, but only for that one class. The setup method in other classes run fine, and in this class as well when it runs by itself. Any suggestions or ideas for what to look at? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/

2 2

ruby-build package waiting to be reviewed.
by Tejas Dinkar 07 Sep '11

07 Sep '11

Hi, I've created packages both for ruby-build and for rbenv. These two packages can be used as an alternative to rvm to manage ruby versions. I have created a package request for ruby-build here: https://bugzilla.redhat.com/show_bug.cgi?id=735672 There is at least one bug with rbenv, and it not letting you use the system ruby, which is why I haven't created a package request for rbenv, though you can find the spec file here: http://tejas.fedorapeople.org/rbenv/ I would appreciate it if someone could look through the specs, and approve the ruby-build request. Any thoughts? Tejas -- Tejas Dinkar C42 Engineering

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig September 2011