Packaging talk:Ruby

From FedoraProject

Revision as of 10:56, 15 February 2011 by Mtasaka (Talk | contribs)

Jump to: navigation, search

The following metadata was found in MoinMoin that could not be converted to a useful value in MediaWiki:

  •  : These two files are symlinks into %gemdir created in %install
  • acl: Known:read,write All:read

The short tutorial how to put an rpm file created with gem2rpm in compliance is here:


Testsuite execution

The most, if not all gems contains their test suite, which is commonly executed during build. This might be in most cases achieved by running rake task such as:

rake spec

However this has some cavities. The problem is mainly that Rakefile usually contains not just the "spec" or "test" task for test suite execution, but also packaging tasks etc. These tasks usually depends on other gems, such as "Hoe". This brings in unnecessary dependencies and polution. Therefore, please prefer to execute the test suite as follows:


RUBYOPT="I%{buildroot}%{geminstdir}/lib Itest" testrb test/test_*


RUBYOPT="I%{buildroot}%{geminstdir}/lib Itest" ruby -e "Dir.glob('test/**/test_*').each {|t| require t}"


RUBYOPT="I%{buildroot}%{geminstdir}/lib Ispec" spec spec/

Additional notes

If the test suite has more dependencies, RUBYOPT can additionally enforce usage of RubyGems. This apply for all test frameworks mentioned above.

RUBYOPT="rubygems I%{buildroot}%{geminstdir}/lib Ispec" spec spec/

Why? Just adding "BR: rubygem(hoe)" and executing $ rake test" is much simpler and easier to maintain. Also using $rake check is useful because it can check if the Rakefile itself is valid or not. Please avoid such comprecated and unneeded craft as much as possible which makes spec file less readable and less maintainable. Note that BuildRequires != Requires. Adding BuildRequires does not add "runtime" dependency. If running $ rake check requires additional packages, please try to add them to Fedora project when possible. It is more useful than resorting to unusual way. - 2011-02-01 UTC 12:45 Mamoru

By the way for rspec it seems that some testsuite need rspec 1, and others need rspec 2. So should we rename rspec 2 to rubygem-rspec2 and try new review request? (And again, if some testsuite needs rspec 2 for %check, we should package it, not try to avoid using it) - Mamoru

2011-02-01 UTC 13:15 vondruch: I have nothing against adding required packages into Fedora, but I am against package pollution. Packages such as Hoe, Bundler, Rubyforge, they are useful for developer. Useful if you want to have every development dependency or create gem. They should be of course available in Fedora. But requiring them because you would like to be sure that test suite passes? It is pain.

If you want to test something in mock and the package your test "depends" on is not available in repository yet, then you are doing nothing else than installing manually packages for mock. If you require rake, it brings in immediately also dependency on RubyGems which means you have immediatelly polluted your load path with libraries you don't know. This makes execution of test suite as fragile as my magic commands.

I even don't want to mention test suites I met in recent time, which tried to install their dependencies during test suite execution. This is plain wrong.

And regarding the RSpec ... The gems I have packaged recently depends on RSpec2, but with some effort, the conversion for RSpec1 was possible with some minor cavities, like conditional execution of some example groups which is not supported by RSpec1.

If we are going ahead with direct upgrade of Rails 2.3 to Rails 3, without any alternatives, I would like to choose the same approach for RSpec (although I am aware that it might be more painful).

The only problem could be rspec-rails gem IMO. But I don't believe there are many gems which depends on it. How many Rails applications we have packaged? But they will be enforced to be migrate somehow to Rails 3 anyway.

2011-02-01 17:00UTC - Mamoru Testing is for development purpose (that is why we usually split test/ spec/ directories or so into -doc subpackage), so it is fairly natural to add (BuildRequires) dependency for testing suite. If you say installing them "pollutes" your environ, feel free to say so, however again it is fairly natural. It is more and more fragile to use such complicated craft than to just installing needed dependency, again your way is much harder to read and maintain. Please just package and install the needed dependency. Again %check suite is for developing purpose, i.e. - It is useful for people developing or maintaining the package, not needed on runtime (i.e. normal user). It is why we distinguish "BuildRequires" and "Requires". Normal user wouldn't need "BR" pkgs or won't have to do test suite.

This is similar to that normal people wouldn't install gcc, foo-devel or other developent-purpose pkgs. You seem to just be confused about "BuildRequires" and "Requires", or "maintainer" and "normal user". Please don't feel it "pain" to install development pkgs such as hoe, rubyforge and so on, if you are maintainer.

Also it is preferable that we as "maintainer" check if $ rake test as provided by the upstream actually works or not after installing the needed pkgs for testsuite. If it does not work, we just report it upstream as maintainer. However again it is not what "normal user" is expected to do and they won't have to install such development-purpose pkgs.

2011-02-10 15:32 UTC vondruch: I am not confused about BuildRequires. I understand it perfectly as far as I can say. And I am basing my statement on experiences from recent time. And I understand perfectly that it is very beneficial to execute test suite (for example Sinatra was broken in Rawhide until today, because its test suite was not executed during build time). The only purpose of the test suite from packager point of view is to ensure that whoever will build the package later will get correct result (current mass rebuild is good example).

The developer have different needs and it is completely different topic (we would call them DevelRequires ;) ). And I am speaking about developer in sense of the upstream package developer. He needs to provide gem for or rubyforge. Therefore it is natural that he needs hoe for example.

Nevertheless, I have to oppose your statement about "complicated craft". Actually my proposal is using the most straight forward way how to execute test suite. And that is exactly what I want during build time. Using "rake test" or "rake spec" is nowhere standardized. What is happening later is just magic. Have you ever noticed that RubyGems are required by rake? Is that correct in the days of Bundler, which doesn't rely on RubyGems in runtime? Some projects doesn't provide Rakefile at all.

From what I have seen in recent times, even developers of upstream gems doesn't understand their test suites. For example every test/spec file should be possible to execute separately. Which is not case for example for sunspot gem. And you want to rely on such developers or test suites? You believe that the rakefile is correct? Will you just blindly setup dependencies, because they are require by Rakefile itself? Honestly, will you check them? If there is some obsolete dependency, which is not in use anymore, how will you discover it?

2011-02-15 11:00 UTC - Mamoru

> using "rake test" or "rake spec" is nowhere standardized. And the way you provided is really far away from what you call "standard". Do you think that "for f in tests/* ; do <run> $f ; done" is the standard way for general "Makefile"-based pkgs? We should base on what we do on standard autotool-based pkgs, that is why "Rakefile" is provided. > Have you ever noticed that RubyGems are required by rake? Why not? rake is installed as "rubygem-rake" on Fedora, so why wouldn't I notice it? (I am also listed in %changelog). And why it is annoyance for you?

> Some projects doesn't provide Rakefile at all. Where did I say that every projects must provide Rakefile?

> From what I have seen in recent times, even developers of upstream > gems doesn't understand their test suites. If so we package maintainers should teach the upstream to fix it.

> You believe that the rakefile is correct? Again it Rakefile is not correct, we should fix it or ask the upstream to fix it. It is what maintainers are expected to do.

> Will you just blindly setup dependencies, because they are require by > Rakefile itself? Honestly, will you check them? If there is some obsolete > dependency, which is not in use anymore, how will you discover it? Won't you check it?? Reviewers would check such dependency of course, I guess?

Please know that I have commented in review requests many times that "this dependency is written in Rakefile, however it is actually not needed. Kill such dependency". Again like that you should fix that if the scripts in gem file are broken you must fix it, if Rakefile is broken you should fix it.

Think in this way. Wouldn't you check the dependencies written in gemspec file or installed ruby scripts? (for example, wouldn't you check "require " statement in all the installed ruby scripts? I always check them) This is not specific to ruby based packages. For python-based scripts we should check every "import " statement during review request. So why don't you check Rakefile's dependency? Well, you are saying that _you_ don't check the "rightness" of Rakefile?