| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
We should first attempt to run commands through Rails command, and then
fall back to trying the commands tasks.
Because eventually the commands tasks should be their own commands.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The class level version is responsible for changing a task name to
command name, then finding a command and run it if there is one.
The instance level `run` then makes sure arguments have been parsed
into `@options` and runs the command by sending it.
`Rails::Commands::Command.run` returns true to make it work within
`Rails::CommandsTask`, but won't in the future when it handles
all option parsing.
|
| |
|
|
|
|
|
|
| |
When `parse_options_for` was called for a command that
hadn't set up any option parsing with `options_for`, the `call` method
would be sent to `-> {}`, which didn't like to be passed two arguments.
Switch to `proc {}` which can accept several arguments.
|
| |
|
|
|
| |
I want to streamline the wording around `command`, and not
start pondering about instances.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `ARGV` constant in Ruby is not a string, it's an array as demonstrated
by running:
```
$ ruby -e "p ARGV"
=> []
$
$ ruby -e "p ARGV" test/file.rb --version=2
=> ["test/file.rb", "--version=2"]
```
|
| |
|
|
|
|
| |
* Ditch the instance methods local variable.
* Prefer Ruby's default nil return, and remove else branch.
|
| |
|
|
|
|
|
|
| |
Checking that a command exists before running it is an implementation detail
of the Rails command and Rake task world right now.
Eventually I'd like to get rid of `exists?`, when I've worked out another way
to fall back to run the old tasks.
|
| |
|
|
|
| |
Users shouldn't have to lookup the command name for a task. Put it in
the private section, so it doesn't show up in any generated documentation.
|
| |
|
