Can't load spec file

[hasimo]

 %  rspec transactional_database_support_spec.rb 
/Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/configuration.rb:230:in `require': no such file to load -- transactional_database_support_spec.rb (LoadError)
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/configuration.rb:230:in `block in require_files_to_run'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/configuration.rb:230:in `map'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/configuration.rb:230:in `require_files_to_run'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/runner.rb:42:in `configure'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/runner.rb:28:in `run'
        from /Users/sulky/.rvm/gems/ruby-1.9.2-head/gems/rspec-core-2.0.0.beta.8/lib/rspec/core/runner.rb:12:in `block in autorun'

% ruby -v                    
ruby 1.9.2dev (2010-05-18 revision 27873) [x86_64-darwin10.2.0]

Ruby1.9.2: current_path( . ) is deleted from $LOAD_PATH
I fixed.
http://github.com/hasimo/rspec-core/commit/c8ce7716ccbac1b94353ed43d0ae50cface06225

[dchelimsky]

Thanks for the patch, but since that's how Ruby 1.9.2 works, I'd rather change all the features to read "rspec ./transactional_data_support_spec.rb".

[eregon]

That sounds a bit weird to me I have to explicitly use an absolute path to run rspec...
rspec spec and rspec spec/lib_spec.rb will both fail, so I have to use the './' which is very not handy.
Could you please use the patch proposed for 1.9.2 ?

That made me think rspec was broken when I tried the first time... At least, it's counter-intuitive.

Also, rspec does not see file in ./spec and then does nothing.

[dchelimsky]

This is a change made in ruby-1.9.2 that will impact every Ruby command line tool, not just RSpec.I agree it feels counter-intuitive, but that is because previous versions of Ruby defied Unix convention, and we've all grown accustomed to it.

Here is some background on why '.' on the LOAD_PATH is risky business:
http://www.faqs.org/faqs/unix-faq/faq/part2/section-13.html. Not sure if this was the motivation or not, but perhaps it helps to provide some context.

[dchelimsky]

It turns out that you can add "-I." to a .rspec file in the project root (or ~/.rspec for global settings).

[eregon]

It turns out that you can add "-I." to a .rspec file in the project root (or ~/.rspec for global settings).

Thanks for the tip, but I think every 1.9.>=2 user would like this option to be a default.

P.S.: I say below why doing "-I." is not really a good idea.

[dchelimsky]

I'll consider that. We could have a -E flag (or similar - the cap indicating its relationship to the -I flag) that would Exclude a dir from the load path. I definitely want it easy to turn off.

[eregon]

This is a change made in ruby-1.9.2 that will impact every Ruby command line tool, not just RSpec

Only a part of ruby command line tools,
only the ones that did require [ARGV[i] not File.expanded]

By example, sass would not be affected I think, as it does not concerns relative ruby files (so no require).
So only the require ability with relative path as been removed (and replaced by require_relative to be sure of what you require and have less conflicts).

About the link, I agree having '.' in PATH(general) is a bad idea. And I do prefer the 1.9.2 way.
But the change was not made to make people use ./spec/file.rb instead of spec/file.rb.
The change was made to stop confusion when requiring a script (I believe).

In all command line tools (general meaning), how much don't accept relative path? Well I don't know a single one that I use frequently. And I do use the shell ;)

btw, ruby spec/my_spec.rb works if you require the libs and 'rspec' yourself.
So, clearly, rspec is just more handy to run specs.
It's a cool feature it adds ./lib to the $LOAD_PATH.
But then why should we use an absolute path? Why should we need this './' ?

So, clearly, adding '.' to the $LOAD_PATH is a bad idea.
But I think that File.expand_path(file) for the ARGV given to the script is reasonable (and probably even more secure).

What do you think?

P.S.: About the patch proposed, maybe it should be better files_to_run to be only absolute paths, so they are expanded when interpreted from the command line.
(in Configuration.files_or_directories_to_run= I think is the best.
Adding file = File.expand_path(file) before the 'if' by example)

[dchelimsky]

The problem with using absolute paths is that's what gets stored for backtraces. Right now it's very easy to scan the backtrace to find the file/line of a failure because it starts with "./spec". I wouldn't mind doing require_relative for ruby-1.9.2 instead if that solves the problem but leaves the backtrace as/is. I'll look into that.

[eregon]

The problem with using absolute paths is that's what gets stored for backtraces. Right now it's very easy to scan the backtrace to find the file/line of a failure because it starts with "./spec".

Why is it a problem? Is it not possible to just "remember" the files loaded?
How do you use this backtrace ?
Anyway these absolute paths could be made relative very easily.
Can you show me in the code where it would actually be a problem?

Adding how I said (file=File.expand_path(file)) produce the usual message if sth is failling:
"# ./spec/my_spec.rb:15:in `block (2 levels) in <top (required)>'"

I wouldn't mind doing require_relative for ruby-1.9.2 instead if that solves the problem but leaves the backtrace as/is. I'll look into that.

Ok. But I think the solution with absolute paths would be better.

[dchelimsky]

Done. http://github.com/rspec/rspec-core/commit/dff65cd7eaa68379812ffc8cd20a6693f24f74c0

[eregon]

Thanks :)