Bugs item #27507, was opened at 2009-12-01 21:36 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126
Category: `gem install` command Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: Ryan Davis (zenspider) Assigned to: Ryan Davis (zenspider) Summary: Remove -t from gem install Initial Comment: this is a message body. ---------------------------------------------------------------------- >Comment By: Luis Lavena (luislavena) Date: 2010-11-13 12:12 Message: Daniel Please point me to the right CPAN of a module that does MySQL? Also, point me to one CPAN module that also does Memcached. How there are installed and tested if the user do not have MySQL or Memcached installed? We are not talking about a pure-ruby or Ruby+C gems that these tests/specs can be run. We are talking that for certain projects, preconditions are required. Take for example testing ActiveRecord, see its dependencies: https://rubygems.org/gems/activerecord There is no declared development dependencies because the project is developed differently: https://github.com/rails/rails The gem is part of one single repository. Will be aweomse if this worked during installation, but how you solve the issue for installation of gem binaries? How you test it if your service/dependency is not local on the user machine? Not counting with the fact that some tests might actually write stuff to these databases/memory of their users installation. We want that? ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2010-11-13 12:06 Message: I would argue that requiring the user to check out the source and run the tests is generally going to be a burden most people won't waste their time on. They'll just assume that it works. I'm tainted by my Perl background here, but with CPAN all tests are run automatically (by default) when installing via the CPAN shell. The module will not install if any tests fail, except by force. In addition, test failures can be automatically reported to the CI farm that they've setup. Perl has multiple testing frameworks, yet somehow they manage to work. I think we're going down the wrong path here. I'd rather establish that all gems follow some sort of convention (perhaps in the spec) with regards to testing, and how tests should be run, that the "-t" option could then hook into. Regards, Dan ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-11-13 11:27 Message: Yes please. Lot of projects do testing differently. Even if you declare all the development dependencies it also depend on certain tools or certain services been installed in the user machine. These are not self contained. If the user wants to run tests, then look for the source, clone/checkout and follow the developer instructions. That is more easy than maintain a command that cannot solve all the aspects of "testing" a gem. ---------------------------------------------------------------------- Comment By: John Barnette (jbarnette) Date: 2010-11-13 11:00 Message: I think -t should die. Other folks? ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-12-03 13:29 Message: I meant a property in the gem spec which would point to an executable test suite script - e.g. spec.test_script = test/test_suite.rb. If this property existed, it would be used and the return code from the script would indicate test success/failure. May be overkill and not worth modifying the spec; it was just an idea to allow people to use any testing framework they want. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-12-03 05:15 Message: Chad, what do you mean by a "test suite script"? I was thinking a -r option to run the 'test' Rake task, if it exists. I also realized that the approach suggested won't work for rspec, for example, because simply requiring an rspec test script doesn't generate any output. It looks like it assumes you're always running 'spec' from the command line directly. Regards, Dan ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-12-01 23:49 Message: 'Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files"' - good idea. And/or add an additional spec parameter for a test suite script... ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2009-12-01 23:45 Message: Is there a reason we can't just make -t run "ruby -I spec.lib spec.test_files" ? ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=575&aid=27507&group_id=126 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
