Migration from RSpec 1.3 to RSpec 2.x
by Vít Ondruch
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.
11 years, 3 months
Re: Migration from RSpec 1.3 to RSpec 2.x
by Shawn Starr
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
11 years, 3 months
Review Request & Need Sponsor: Ruby 2.3.12 in Fedora 15+
by Emanuel Rietveld
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
11 years, 6 months
FUDCon:Milan 2011 - Ruby SIG meeting
by Vít Ondruch
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 years, 8 months
Do we have stats on how many people use the various rubygem rpms / How can we better package rails apps?
by Tejas Dinkar
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
11 years, 8 months
Test runs by itself, fails when run with everything...
by Darryl L. Pierce
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/
11 years, 8 months
ruby-build package waiting to be reviewed.
by Tejas Dinkar
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
11 years, 8 months
