Bugs item #27507, was opened at 2009-12-01 16: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: Closed 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: Ryan Davis (zenspider) Date: 2010-11-13 09:40 Message: done ---------------------------------------------------------------------- Comment By: Ryan Davis (zenspider) Date: 2010-11-13 08:57 Message: This has been discussed at length already. It just needs to go. We can not support all the different ways that people test. "I'd rather establish that all gems follow some sort of convention" This is just not realistic, considering we DID establish a convention and it obviously didn't work. ---------------------------------------------------------------------- Comment By: Daniel Berger (djberg96) Date: 2010-11-13 07:44 Message: Luis, that doesn't even make sense to me. You aren't going to install a MySQL gem unless you already have MySQL installed. The installation would fail regardless of -t. CPAN modules do not (typically) bundle 3rd party dependencies. I'm not sure what you're getting at with activerecord. Dependencies would be installed before the tests would be run for whatever gem you've installed. Also, activerecord may be part of the rails bundle, but it can be installed separately afaik. I'm not sure how gem binaries would be different. The files + directory structure could still be created (as they are even for failed gem installs in the case of C extensions), and the tests could be run from there. Or it could be created in a temp directory. If the tests fail they're cleaned up. Development dependencies would be necessary to install, at least temporarily, to run the tests. They could be deleted afterwards. As to writing to the database, I really don't see that happening. What, they just guessed your username and password? Honestly, I would consider such behavior malicious. Note that there's nothing stopping people from doing something like that now via the extconf.rb file. In practice what I've seen from CPAN database libraries is an interactive shell that asks me if it's ok to create a temporary schema, give it a username and password, and do its thing. Dan ---------------------------------------------------------------------- Comment By: Luis Lavena (luislavena) Date: 2010-11-13 07: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 07: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 06: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 06:00 Message: I think -t should die. Other folks? ---------------------------------------------------------------------- Comment By: Chad Woolley (thewoolleyman) Date: 2009-12-03 08: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 00: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 18: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 18: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
