Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rails Best Practices Add Link to Warning #117

Merged
merged 3 commits into from
Aug 14, 2013

Conversation

calveto
Copy link

@calveto calveto commented Aug 8, 2013

This is in reference to #87.

I changed the format of the output of Rails Best Practices to yaml, so we can parse the url. This url provides a link to rails-bestpractices.com page, which describes the problem and provides a solution.

@ghost ghost assigned bf4 Aug 8, 2013
end

def command
%Q(mf-rails_best_practices --format yaml --output-file #{output_file} .)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I wonder if there's a better way to do this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think you could require the libraries directly?

path = '.'
options = {'format' => 'yaml', 'without-color' => true, 'silent' => true} #output-file, with-git, with-hg, debug
analyzer = RailsBestPractices::Analyzer.new(path, options)
analyzer.analyze
# analyzer.output #writes to output-file
@output = analyzer.errors # [ Array<RailsBestPractices::Core::Error> ]
# useful methods on each error: type, url, message, filename, short_filename, first_line_number, git_commit, git_username, hg_commit, hg_username

See flyerhzm/rails_best_practices#172

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, don't even think you'd need the output_file/options stuff...

require 'rails_best_practices'
path = '.'
analyzer = RailsBestPractices::Analyzer.new(path,{})
analyzer.analyze
# analyzer.output
@output = analyzer.errors

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You'll still want options = {'silent' => true} to turn off the progress bar

@calveto
Copy link
Author

calveto commented Aug 9, 2013

Thanks for the comments. I will take a look at this over the weekend, same for #118

@bf4
Copy link
Member

bf4 commented Aug 9, 2013

On the other hand, it would not be inconsistent with the current implementation to do exactly what's in this PR. I think we just, in general, want to move away from shelling out.

This link provides a description and a solution to the problem.
We now have the URL, so we can provide a link to rails-best-pracitces.com
By calling the lib directly we can avoid IO overhead, however we want to
be sure that the RailsBestPractices maintains the interface we are
expecting, since it's not a publicly advertised interface.
I have added some specs that will error if the interface to
RailsBestPractices changes.

huh
@calveto
Copy link
Author

calveto commented Aug 12, 2013

I think moving away from shelling out is a good direction to go. Since RailsBestPractices doesn't have a public interface I added a few tests that will fail if they change the interface that is being used. Let me know if you have any more thoughts.

mf_debug "** #{command}"
@output = `#{command}`
mf_debug "** Rails Best Practices"
path = '.'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be a configured option in the init.rb, so that it can be called here as options.fetch(:path)

I wonder if its worth including the 'silent' option in the init.rb, as well.

In any case, we should definitely allow other run options to be passed in and merged into {'silent' => true} (ensuring the keys are strings?) so that someone could run with git or hg integration if desired.

@bf4
Copy link
Member

bf4 commented Aug 12, 2013

Looks awesome! Please rebase off of master and force push. We have the tests passing now

git checkout master
git fetch upstream
git reset --hard upstream/master # or whatever your remote branch to metrcfu/metric_fu is called
git checkout rails-best-link-to-warning
git rebase master # there shouldn't be many problems. If there are, then git merge master
rspec # they should all pass now
git push -f origin rails-best-link-to-warning

@bf4
Copy link
Member

bf4 commented Aug 12, 2013

It would be great if you also updated the readme and/or .metrics file with how to configure by reference to, (thinking out loud)

@calveto
Copy link
Author

calveto commented Aug 12, 2013

I'm getting in interesting error when running all the test after rebasing with master from upstream. I get the following exception when running spec/metric_fu/data_structures/line_numbers_spec

RUBY PARSE FAILURE: ArgumentError   wrong number of arguments (1 for 0) FILE:   SEXP:nil
    CONTENT:"class Foo\n  def stuff\n    5\n  end\nend\n\nclass Bar\n  def stuff\n    1\n  end\nend\n"
    /Users/calvert/.rvm/gems/ruby-1.9.3-p448/gems/code_analyzer-0.3.2/lib/code_analyzer/sexp.rb:16:in `line'
/Users/calvert/.rvm/gems/ruby-1.9.3-p448/gems/ruby_parser-3.1.3/lib/ruby19_parser.rb:4751:in `_reduce_323'
(eval):3:in `_racc_do_parse_c'
(eval):3:in `do_parse'
/Users/calvert/.rvm/gems/ruby-1.9.3-p448/gems/ruby_parser-3.1.3/lib/ruby_parser_extras.rb:983:in `block in process'
/Users/calvert/.rvm/rubies/ruby-1.9.3-p448/lib/ruby/1.9.1/timeout.rb:69:in `timeout'
/Users/calvert/.rvm/gems/ruby-1.9.3-p448/gems/ruby_parser-3.1.3/lib/ruby_parser_extras.rb:973:in `process'
/Users/calvert/.rvm/gems/ruby-1.9.3-p448/gems/ruby_parser-3.1.3/lib/ruby_parser_extras.rb:1292:in `process'
/Users/calvert/code/metric_fu/lib/metric_fu/data_structures/line_numbers.rb:17:in `initialize'
/Users/calvert/code/metric_fu/spec/metric_fu/data_structures/line_numbers_spec.rb:44:in `new'
/Users/calvert/code/metric_fu/spec/metric_fu/data_structures/line_numbers_spec.rb:44:in `block (3 levels) in <top (required)>'
...

You can see from the stack trace that the Sexp#line method is being called with the wrong number of arguments.

From what I can gather RailsBestPractices is requiring the CodeAnalyzer gem, which overrides Sexp#line and does not expect any arguments to be provided.

This test will pass when I do not require rails_best_practices I think it is calling the Sexp#line method from sexp_processor

Any thoughts?

@bf4
Copy link
Member

bf4 commented Aug 12, 2013

Is it just a test failure?

@calveto
Copy link
Author

calveto commented Aug 13, 2013

Nope. It breaks when running metric_fu as well. 😦

@bf4
Copy link
Member

bf4 commented Aug 13, 2013

Wow, that is really annoying. The reason why it's even possible is because code_analyzer uses ripper and sexp_processor. If it used ruby_parser and sexp_processor, this hack would have failed a while ago.

I'm not really sure what to do, to keep this code working, besides, for the moment, make sure rbp runs last and is required when it runs.

@bf4
Copy link
Member

bf4 commented Aug 13, 2013

bundle console

file_sexp = RubyParser.new.parse(File.read('./lib/metric_fu/data_structures/line_numbers.rb'))
file_sexp.line => 3
require 'code_analyzer'
file_sexp.line => :module # and can no longer use RubyParser

@bf4
Copy link
Member

bf4 commented Aug 13, 2013

Saweet! Got the fixes merged in to rbp and code_analzyer and Richard Huang has released new versions:

You should be able to update the rbp in the gemspec now and it'll just work. -> ['>= 1.14.1', '~> 1.14']

@bf4
Copy link
Member

bf4 commented Aug 14, 2013

Rebase off master and force push. It should work now. I put the rbp dependency in master 593f7ee

@bf4
Copy link
Member

bf4 commented Aug 14, 2013

Nevermind, I'll just do it from the commandline

@bf4 bf4 merged commit f6799f8 into metricfu:master Aug 14, 2013
@bf4
Copy link
Member

bf4 commented Aug 14, 2013

Congrats!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants