Giter Club home page Giter Club logo

devtools's Introduction

devtools

Build Status Dependency Status Code Climate

Metagem to assist development. Used to centralize metric setup and development gem dependencies.

Installation

Add the gem to your Gemfile's development section.

group :development, :test do
  gem 'devtools', '~> 0.1.x'
end

RSpec support

If you're using RSpec and want to have access to our common setup just adjust spec/spec_helper.rb to include

require 'devtools/spec_helper'

Credits

The whole ROM team that created and maintained all these tasks before they were centralized here.

Contributing

  • Fork the project.
  • Make your feature addition or bug fix.
  • Add tests for it. This is important so I don't break it in a future version unintentionally.
  • Commit, do not mess with Rakefile or version (if you want to have your own version, that is fine but bump version in a commit by itself I can ignore when I pull)
  • Send me a pull request. Bonus points for topic branches.

License

See LICENSE file.

devtools's People

Contributors

alejandrobabio avatar backus avatar barthez avatar code-later avatar dkubb avatar mbj avatar plexus avatar shingara avatar skade avatar snusnu avatar solebared avatar solnic avatar zaidan avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

devtools's Issues

Add rubocop-rspec

I mentioned this in the mutant slack chat a few days back. I'll lookup and paste the relevant discussion in a comment on this issue. At some point I would like to look into the following regarding rubocop-rspec:

1. How much time would adding rubocop-rspec add to rubocop's average runtime and therefore devtools runtime as a whole

Intuitively, it doesn't seem like the 8 cops that rubocop-rspec provides would significantly impact the runtime on top of the ~240 cops rubocop provides. With that said, @mbj has said before he doesn't want to slow down devtools much more until the everything is parallelized, so benchmarking the impact of adding rubocop-rspec is probably still important.

2. What the false positive rate is for each cops that it adds

Some of the cops might yield false positives regularly enough that the cops end up not being worth it. If only a few of the cops end up being worth it when accounting for false positives then the gem probably shouldn't be added at all.

Trouble calling reek from rake

L2G/guard-xmllint@a3aca17

In this project, for some reason I can't get reek to run from the metrics:reek task, but if I run reek directly (bundle exec reek), it's fine:

$ bundle exec rake metrics:reek
bundler: command not found: c:/foss/github/L2G/guard-xmllint/vendor/ruby/1.9.1/gems/reek-1.3.2/bin/reek
Install missing gem executables with `bundle install`
rake aborted!
Smells found!
c:/foss/github/L2G/guard-xmllint/vendor/ruby/1.9.1/gems/reek-1.3.2/lib/reek/rake/task.rb:100:in `run_task'
c:/foss/github/L2G/guard-xmllint/vendor/ruby/1.9.1/gems/reek-1.3.2/lib/reek/rake/task.rb:92:in `block in define'
Tasks: TOP => metrics:reek
(See full trace by running task with --trace)
$ bundle exec reek -c config/reek.yml lib
lib/guard/xmllint.rb -- 1 warning:
  Guard::XmlLint has no descriptive comment (IrresponsibleModule)
lib/guard/xmllint/version.rb -- 1 warning:
  Guard::XmlLint has no descriptive comment (IrresponsibleModule)

This is on a Windows 7 system running Ruby 1.9.3p392 (i386-mingw32).

Ability to exclude namespaces from mutation

When running the metrics:mutant task against axiom, mutant will also include Axiom::Types, which obviously causes lots of mutation failures.

Ideally I would be able to specify the (one or more) namespaces to exclude in the config/mutant.yml file.

Should development dependencies still be specified in the gemspec?

Right now we have a development group that specifies the latest stable version of rake, rspec and yard. This information is no longer included in the gemspec, so it cannot be displayed on the rubygems.org site and there's no way to know the development dependencies without inspecting the Gemfile.

My question, probably mostly for @mbj, is whether or not the Gemfile is the best place for development deps, or if it better to have them in the gemspec?

Update rubocop version to ~> 0.18.1

Current rubocop version is set to ~.0.16.0.
It is incompatible with rainbow version 2.0.0.
You will get an error like the following:

Inspecting 104 files
undefined method `color' for ".":String

Change rubocop to 0.18.1 solves this problem.

Assert config file field types

#91 refactored the flay implementation and killed some mutations along the way. An unintended side effect was that configuration that specifies total_score as a float like so

---
threshold: 12
total_score: 88.0

as opposed to an integer

---
threshold: 12
total_score: 88

now produces

Flay total is now 88, but expected 88 bundle exec rake ci returned exit code 1

To avoid issues like this, we should assert expected types on configuration load.

rake installation errors

Hi
I keep getting this error and I cant install devtools at all. I think rake is playing hard ball :/

I know there were issues with rubygems 2.0 so i downgraded my system to 1.8.25 and most if not all other gem installs work except devtools

$ bundle exec rake devtools:sync --trace
rake aborted!
key not found: "name"
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/bundler/gems/devtools-863167ed6a31/lib/devtools/config.rb:24:in `fetch'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/bundler/gems/devtools-863167ed6a31/lib/devtools/config.rb:24:in `block in attribute'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/bundler/gems/devtools-863167ed6a31/tasks/metrics/mutant.rake:18:in `block in <top (required)>'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/task_manager.rb:196:in `in_namespace'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/dsl_definition.rb:104:in `namespace'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/bundler/gems/devtools-863167ed6a31/tasks/metrics/mutant.rake:3:in `<top (required)>'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/rake_module.rb:25:in `load'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/rake_module.rb:25:in `load_rakefile'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/default_loader.rb:6:in `load'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/application.rb:663:in `load_imports'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/application.rb:596:in `raw_load_rakefile'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/application.rb:89:in `block in load_rakefile'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/application.rb:160:in `standard_exception_handling'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/application.rb:88:in `load_rakefile'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/application.rb:72:in `block in run'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/application.rb:160:in `standard_exception_handling'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/lib/rake/application.rb:70:in `run'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/gems/rake-10.0.4/bin/rake:33:in `<top (required)>'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/bin/rake:23:in `load'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/bin/rake:23:in `<main>'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/bin/ruby_noexec_wrapper:14:in `eval'
/Users/safarista/.rvm/gems/ruby-1.9.3-p448@sinatros/bin/ruby_noexec_wrapper:14:in `<main>'

Release 0.1.2?

There should be a new version of devtools now that reek is reenabled and upgraded: ddef8c1

Tiny naming change

Currently we have the metrics task available under the ci namespace. The metrics tasks themselves are under the metrics namespace as a top level namespace. For example:

rake ci
rake ci:metrics
rake metrics:reek

This is a tiny thing – but it makes me sad 😉 I would prefer to have the following:

# Version 1:
rake ci
rake metrics
rake metrics:reek

# Version 2:
rake ci
rake ci:metrics
rake ci:metrics:reek

I prefer the first version, because otherwise spec would have to be in ci as well. Are you okay with the change to Version 1?

Ability to configure spec tasks

So. I think it'd be nice if we could generate spec tasks based on configuration. We could have config/specs.yml with:

integration: spec/integration/**/*_spec.rb
unit: spec/unit

...by default and let devtools generate tasks based on that.

Mutant config is not preseeded

I just tried to devtool-ify my gem and it worked like a charm, except one small bump:

config/mutant.yml is preconfigured to your_lib/YourLib. Wouldn't it make sense to try to guess that information from the gemspec? e.g. "my-lib" => My::Lib?

Change README gem version

The README version is now out of date. Since we will like just forget to update this with each new version we should just change it to read

group :development, :test do
  gem 'devtools', '~> 0.1.x'
end

Ignore

Ignore this I opened this on the wrong repo 😢

Mutant config should allow specifying rationals

Before ac80555 I could write my mutant config like this

---
name: my_lib
namespace: MyLib
expect_coverage: 495/750

but now it rejects values which are not floats. This is a pretty big pain for projects which are not yet at 100% mutation coverage. I think we should update this to allow string values so that this previous behavior works. We could coerce using Rational() after mutant's config is loaded if we want to guarantee that it is the proper rational representation.

I'm happy to fix this myself tonight.

Default configs

After going through the configuration settings for devtools on my project, I found that I need a flog.yml inside a config directory. Can it be possible to have defaults set of config files?

Bootstrapping after git clone?

Hi, I'm trying to run bundle install on my local clone of https://github.com/mbj/unparser, a project that uses devtools. I'm running into the problem that this fetches current devtools master and then bombs out because unparser depends on older versions of rake, etc. than devtools. From devtools' README, I gather that the update process involves bundle exec devtools sync. However, since bundle install won't run, I'm left hand-modifying Gemfile.devtools.

Is there a better way, and if so, what is it?

Task to generate changelog

What do you think of implementing something like parser's Rakefile to allow building a changelog from commit history?

task :build => [:generate_release, :changelog]

desc 'Generate Changelog'
task :changelog do
  fs     = "\u{fffd}"
  format = "%d#{fs}%s#{fs}%an#{fs}%ai"

  # Format: version => { commit-class => changes }
  changelog = Hash.new do |hash, version|
    hash[version] = Hash.new do |hash, klass|
      hash[klass] = []
    end
  end

  IO.popen("git log --pretty='#{format}' HEAD", 'r') do |io|
    current_version = nil

    io.each_line do |line|
      version, message, author, date = line.
            match(/^(?: \((.*)\))?#{fs}(.*)#{fs}(.*)#{fs}(.*)$/o).captures
      date = Date.parse(date)

      current_version = "#{$1} (#{date})" if version =~ /(v[\d\w.]+)/
      current_version = "v#{Parser::VERSION} (#{date})" if version =~ /HEAD/

      next if current_version.nil? || message !~ /^[+*-]/

      changelog[current_version][message[0]] << "#{message[1..-1]} (#{author})"
    end
  end

  commit_classes = {
    '*' => 'API modifications:',
    '+' => 'Features implemented:',
    '-' => 'Bugs fixed:',
  }

  File.open('CHANGELOG.md', 'w') do |io|
    io.puts 'Changelog'
    io.puts '========='
    io.puts

    changelog.each do |version, commits|
      io.puts version
      io.puts '-' * version.length
      io.puts

      commit_classes.each do |sigil, description|
        next unless commits[sigil].any?

        io.puts description
        commits[sigil].each do |commit|
          io.puts " * #{commit.gsub('<', '\<').lstrip}"
        end
        io.puts
      end
    end
  end

  sh('git commit CHANGELOG.md -m "Update changelog." || true')
end

devtools shouldn't have dependencies

At the moment it depends on adamantium which depends on backports and I want to ugprade backports to 3.0 in virtus and I can't bkz devtools blocks me.

Also, I don't really think such a tiny tool needs any deps. This just feels too much.

Remove Travis

Currently, the "test suite" is run on Travis. The test suite consists of zero files 😉 Can we just remove Travis including the badge? I think this is just window dressing.

`bundle exec devtools init` breaks

Running bundle exec devtools init, as specified in the Readme, fails with the following:

/usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/devtools-879c5d25fbf4/lib/devtools/site/initializer.rb:35:in `call': undefined method `sync' for #<Devtools::Site:0x007fae5a99c8b0> (NoMethodError)
    from /usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/devtools-879c5d25fbf4/lib/devtools/site/initializer.rb:10:in `call'
    from /usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/devtools-879c5d25fbf4/lib/devtools/site.rb:35:in `init'
    from /usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/devtools-879c5d25fbf4/lib/devtools.rb:94:in `init'
    from /usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bundler/gems/devtools-879c5d25fbf4/bin/devtools:13:in `<top (required)>'
    from /usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bin/devtools:23:in `load'
    from /usr/local/var/rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/bin/devtools:23:in `<main>'

I'm using what's on master (gem 'devtools', git: 'https://github.com/mbj/devtools.git' – again, as instructed in the Readme).

Any clues?

Current version does not work

If you run a bundle update now, it will fail. This broke my build just now. The reason for that is that you refer to a Github Repo that does not exist: snusnu/yardstick. Please fix it ;)

metrics:mutant failure doesn't break task chain in Travis

Locally, this behaves as expected (see below), but in Travis the whole ci task unexpectedly succeeds: https://travis-ci.org/lgierth/promise/builds/11398499

My bundle is locked to mbj/mutant@7e6960263 and rom-rb/devtools@7aee71654b, and I'm a bit puzzled where the task chain gets halted.

$ bundle exec rake ci -t
** Invoke ci (first_time)
** Invoke ci:metrics (first_time)
** Invoke metrics:coverage (first_time)
** Execute metrics:coverage
** Invoke spec:unit (first_time)
** Execute spec:unit
[snip]
** Invoke metrics:yardstick:verify (first_time)
** Execute metrics:yardstick:verify
** Invoke metrics:rubocop (first_time)
** Execute metrics:rubocop
[snip]
** Invoke metrics:flog (first_time)
** Execute metrics:flog
** Invoke metrics:flay (first_time)
** Execute metrics:flay
** Invoke metrics:reek (first_time)
** Execute metrics:reek
0 total warnings
** Execute ci:metrics
** Invoke metrics:mutant (first_time)
** Invoke metrics:coverage 
** Execute metrics:mutant
[snip]
Mutant task is not successful
$ echo $?
1

Enable reek again when upstream issue is fixed.

Currently reek fails with the following error when run on morpher (Valid ruby):

/home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/ast/sexp_extensions.rb:435:in `defines_module?': undefined method `simple_name' for nil:NilClass (NoMethodError)
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:60:in `process_casgn'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:44:in `process'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:83:in `block in process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `each'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:53:in `block in process_module'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:201:in `block in inside_new_context'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:214:in `push'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:200:in `inside_new_context'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:52:in `process_module'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:44:in `process'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:83:in `block in process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `each'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:139:in `process_begin'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:44:in `process'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:83:in `block in process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `each'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:53:in `block in process_module'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:201:in `block in inside_new_context'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:214:in `push'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:200:in `inside_new_context'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:52:in `process_module'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:44:in `process'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:83:in `block in process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `each'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:53:in `block in process_module'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:201:in `block in inside_new_context'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:214:in `push'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:200:in `inside_new_context'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:52:in `process_module'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:44:in `process'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:83:in `block in process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `each'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:82:in `process_default'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:139:in `process_begin'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:44:in `process'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:38:in `result'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/tree_walker.rb:27:in `walk'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/examiner.rb:77:in `run'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/examiner.rb:37:in `initialize'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/cli/reek_command.rb:14:in `new'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/cli/reek_command.rb:14:in `block in execute'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/cli/reek_command.rb:13:in `each'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/cli/reek_command.rb:13:in `execute'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/lib/reek/cli/application.rb:34:in `execute'
        from /home/mbj/.gem/ruby/2.2.3/gems/reek-3.3.1/bin/reek:12:in `<top (required)>'
        from /home/mbj/.gem/ruby/2.2.3/bin/reek:23:in `load'
        from /home/mbj/.gem/ruby/2.2.3/bin/reek:23:in `<main>'

Once there is a fix we can enable it again.

Rubocop deprecation warnings

Hi there!

I am getting

.../config/rubocop.yml - AllCops/Excludes was renamed to AllCops/Exclude
.../config/rubocop.yml - AllCops/Includes was renamed to AllCops/Include
Warning: unrecognized cop EmptyLinesAroundBody found in .../config/rubocop.yml

The first two are trivial the last one is probably linked to
rubocop/rubocop#1399 where the cop was separated into 3 distinct cops. Any preference on defaults before I submit PR?

Nuke rake

This issue is for discussing those ugly stuff we have in:

https://github.com/rom-rb/devtools/blob/master/tasks/metrics/flay.rake

And basically any other .rake file. IMHO rake is superfluous here. Its core feature is dependency resolution for traditional "produce file X before Y". We do not have such a scenario in ROM and ROM-style projects.

Also this code is de-facto unstable. Testing rake tasks is ugly.

A pure ruby implementation of the above talks would be more clean, and easier to maintain. We'd have to provide an additional "tool execution" mechanism, but I think devtools flay would be much easier to memorize/implement/use than rake metrics:flay

I'm open for other arguments!

bundler: command not found: devtools

~/code/ruby/gems/blankgem ‹ruby-2.0.0@blankgem› ‹git:master*› $ cat blankgem.gemspec
# coding: utf-8
lib = File.expand_path("../lib", __FILE__)
$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
require "blankgem/version"

Gem::Specification.new do |spec|
  spec.name          = "blankgem"
  spec.version       = Blankgem::VERSION
  spec.authors       = ["Kurtis Rainbolt-Greene"]
  spec.email         = ["[email protected]"]
  spec.summary       = %q{TODO: Write a gem summary}
  spec.description   = spec.summary
  spec.homepage      = "http://krainboltgreene.github.io/blankgem"
  spec.license       = "MIT"

  spec.files         = Dir["lib/**/*"]
  spec.executables   = Dir["bin/**/*"].map! { |f| f.gsub(/bin\//, "") }
  spec.test_files    = Dir["test/**/*", "spec/**/*"]
  spec.require_paths = ["lib"]

  spec.add_development_dependency "bundler", "~> 1.3"
  spec.add_development_dependency "rspec", "~> 2.14"
  spec.add_development_dependency "rake", "~> 10.1"
  spec.add_development_dependency "yard", "~> 0.8"
  spec.add_development_dependency "kramdown", "~> 1.2"
  spec.add_development_dependency "pry", "~> 0.9"
  spec.add_development_dependency "coveralls", "~> 0.7"
  spec.add_development_dependency "devtools", "~> 0.0.1"
end
~/code/ruby/gems/blankgem ‹ruby-2.0.0@blankgem› ‹git:master*› $ gem list | grep devtools
devtools (0.0.1)
~/code/ruby/gems/blankgem ‹ruby-2.0.0@blankgem› ‹git:master*› $ bundle install                                                                           127 ↵
Resolving dependencies...
Using rake (10.1.1)
Using i18n (0.6.9)
Using multi_json (1.8.4)
Using activesupport (3.2.16)
Using builder (3.0.4)
Using activemodel (3.2.16)
Using erubis (2.7.0)
Using journey (1.0.4)
Using rack (1.4.5)
Using rack-cache (1.2)
Using rack-test (0.6.2)
Using hike (1.2.3)
Using tilt (1.4.1)
Using sprockets (2.2.2)
Using actionpack (3.2.16)
Using mime-types (1.25.1)
Using polyglot (0.3.3)
Using treetop (1.4.15)
Using mail (2.5.4)
Using actionmailer (3.2.16)
Using arel (3.0.3)
Using tzinfo (0.3.38)
Using activerecord (3.2.16)
Using activeresource (3.2.16)
Using blankgem (1.0.0) from source at .
blankgem at /Users/krainboltgreene/Code/Ruby/gems/blankgem did not have a valid gemspec.
This prevents bundler from installing bins or native extensions, but that may not affect its functionality.
The validation message from Rubygems was:
  "FIXME" or "TODO" is not a description

Using bundler (1.3.5)
Using coderay (1.1.0)
Using rest-client (1.6.7)
Using docile (1.1.2)
Using simplecov-html (0.8.0)
Using simplecov (0.8.2)
Using tins (0.13.1)
Using term-ansicolor (1.2.2)
Using thor (0.18.1)
Using coveralls (0.7.0)
Using rack-ssl (1.3.3)
Using json (1.8.1)
Using rdoc (3.12.2)
Using railties (3.2.16)
Using rails (3.2.16)
Using devtools (0.0.1)
Using diff-lcs (1.2.5)
Using kramdown (1.3.1)
Using method_source (0.8.2)
Using slop (3.4.7)
Using pry (0.9.12.4)
Using rspec-core (2.14.7)
Using rspec-expectations (2.14.4)
Using rspec-mocks (2.14.4)
Using rspec (2.14.1)
Using yard (0.8.7.3)
Your bundle is complete!
Use `bundle show [gemname]` to see where a bundled gem is installed.
~/code/ruby/gems/blankgem ‹ruby-2.0.0@blankgem› ‹git:master*› $ bundle exec devtools
bundler: command not found: devtools
Install missing gem executables with `bundle install`

Help install less gems on travis for projects using devtools

In your .travis.yml you have

bundler_args: --without yard guard benchmarks
script: "bundle exec rake ci"

This is because you don't need, for ci, all the gems that devtools provides. However, the naive user of devtools may not know to add this and will end up installing too many gems.

I'm not sure the best implementation of solving this, either documentation, or a post install message, or a travis.yml check, or all.

In metric_fu I use

bundler_args: --without local_development yard metrics guard --path vendor/bundle
cache: bundler # not part of this issue, but tmyk

(It would be really nice if devtools had a general bundle group for everything it includes)

Thoughts?

Make reek, coveralls and simplecov(?) optional

IMO these could also live inside a Gemfile(.devtools). I find myself rarely using reek recently, I don't see much point in coveralls and with mutant's coverage expectation configuration setting, I don't need simplecov either. Dropping the hard dependencies on those would cut down bundle time also.

Why no Ruby gem?

Just curious why this hasn't been packaged as it's own gem.. Is the fact that it creates it's own Gemfile preventing this? I'm sure there are some technical hurdles.. just wondering what they were..

Upgrade to Reek 3

Reek version 3 was released about two weeks ago https://github.com/troessner/reek/releases

One change they made was to move all of their wiki pages into the main repo, so now the --wiki-links flag is useless. This gem doesn't use the wiki links flag, but devtools does make it impossible to upgrade to Reek 3 since it looks the dependency at 2.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.