While trying to develop a simple gem to learn the process, I happened to stumble on this issue: Thor DSL takes in options to a command using the syntax: option :some_option, :type => :boolean, just prior to the method definition.
I am trying to have a dynamic set of options loaded from a file. I do this file read operation in the constructor, but it seems the option keyword for the Thor class is getting processed before the initialize method.
Any ideas to resolve this? Also it would be great if someone can explain how the option keyword works? I mean is option a method call? I don't get the design. (This is the first DSL I am trying out and am a total newbie to Ruby Gems)
#!/usr/bin/env ruby
require 'thor'
require 'yaml'
require 'tinynews'
class TinyNewsCLI < Thor
attr_reader :sources
#sources = {}
def initialize *args
super
f = File.open( "sources.yml", "r" ).read
#sources = YAML::load( f )
end
desc "list", "Lists the available news feeds."
def list
puts "List of news feed sources: "
#sources.each do |symbol, source|
puts "- #{source[:title]}"
end
end
desc "show --source SOURCE", "Show news from SOURCE feed"
option :source, :required => true
def show
if options[:source]
TinyNews.print_to_cli( options[:source].to_sym )
end
end
desc "tinynews --NEWS_SOURCE", "Show news for NEWS_SOURCE"
#sources.keys.each do |source_symbol| # ERROR: States that #sources.keys is nil
#[:hindu, :cnn, :bbc].each do |source_symbol| # I expected the above to work like this
option source_symbol, :type => :boolean
end
def news_from_option
p #sources.keys
TinyNews.print_to_cli( options.keys.last.to_sym )
end
default_task :news_from_option
end
TinyNewsCLI.start( ARGV )
After a bit of tweaking, I think I ended upon a solution that doesn't look too bad. But not sure placing code in module like that is a good practice. But anyways:
#!/usr/bin/env ruby
require 'thor'
require 'yaml'
require 'tinynews'
module TinyNews
# ***** SOLUTION *******
f = File.open( "../sources.yml", "r" ).read
SOURCES = YAML::load( f )
class TinyNewsCLI < Thor
default_task :news_from_source
desc "list", "Lists the available news feeds."
def list
puts "List of news feed sources: "
SOURCES.each do |symbol, source|
puts "- #{source[:title]}"
end
end
desc "--source NEWS_SOURCE", "Show news for NEWS_SOURCE"
option :source, :required => true, :aliases => :s
def news_from_source
TinyNews.print_to_cli( options[:source].to_sym )
end
end
end
TinyNews::TinyNewsCLI.start( ARGV )
Related
Pretty new to Ruby and OO. Studying the text books, and all the articles that google found on Thor.
I have Thor working to capture multiple command line arguments and options. I'd like to do the rest of my programming from outside the Cli < Thor class though, and am having trouble accessing the command line arguments from outside the Cli class.
Questions:
Q1. Can the Cli < Thor class be treated like any other ruby class, or does inheriting from Thor, or the "Cli.start" command, cripple certain functionality of the Cli class versus not using Thor? Asking because I may simply not know how to access an instance variable from outside a class that doesn't use the initialize method. Thor will not let me use the initialize method to bring in the command line variables, probably because initialize is a reserved method name in ruby.
Q2. How can I access the command line argument variables a and b from outside the Thor class?
Here's my code
#!/usr/bin/env ruby
require 'thor'
class Cli < Thor
attr_reader :a, :b
method_option :add, :type => :string, :desc => 'add servers'
method_option :prod, :type => :string, :desc => 'production stack'
desc "tier <stack folder name> <app | web>", "creates an app or web server tier for the stack"
def tier(a,b)
#a = a
#b = b
puts a
puts b
end
end
Cli.start
arguments = Cli.new
puts "the first argument is #{arguments.a}"
Here's the result. Close (maybe). No errors, but arguments.a is nil.
$ ./create.rb tier a b
a
b
the first argument is
--
puts arguments.tier.a
threw the error:
./create.rb:11:in `tier': wrong number of arguments (0 for 2) (ArgumentError)
from ./create.rb:23:in `<main>'
The following works without Thor and using an initialize method and attr_reader, straight out of the text books. Can't figure out how to access the variables from a non-initialize method though.
#!/usr/bin/env ruby
class Cli
attr_reader :a, :b
def initialize(a,b)
#a = a
#b = b
end
end
arguments = Cli.new("a","b")
puts arguments.a
outupt:
$ ./create_wo_thor.rb
a
Instantiating your Cli class doesn't make much sense; that's not how Thor is designed.
You have a few options to access internal data from outside the class. If there are only a few variables that you want access to, storing them as class variables and making them available through getters (and setters, if you need them) would work:
require 'thor'
class Cli < Thor
method_option :add, :type => :string, :desc => 'add servers'
method_option :prod, :type => :string, :desc => 'production stack'
desc "tier <stack folder name> <app | web>", "creates an app or web server tier for the stack"
def tier(a,b)
##a = a
##b = b
puts a
puts b
end
def self.get_a
##a
end
def self.get_b
##b
end
end
Cli.start
puts "the first argument is #{Cli.get_a}"
This works as you hope:
$ ./thor.rb tier a b
a
b
the first argument is a
I prefer the following, using a global Hash:
require 'thor'
$args = {}
class Cli < Thor
method_option :add, :type => :string, :desc => 'add servers'
method_option :prod, :type => :string, :desc => 'production stack'
desc "tier <stack folder name> <app | web>", "creates an app or web server tier for the stack"
def tier(a,b)
$args[:a] = a
$args[:b] = b
puts a
puts b
end
end
Cli.start
puts "the first argument is #{$args[:a]}"
Last, I'd be remiss not to point out that all the command line arguments are available in the global ARGV, anyway:
require 'thor'
class Cli < Thor
method_option :add, :type => :string, :desc => 'add servers'
method_option :prod, :type => :string, :desc => 'production stack'
desc "tier <stack folder name> <app | web>", "creates an app or web server tier for the stack"
def tier(a,b)
puts a
puts b
end
end
Cli.start
puts "The first argugment is #{ARGV[1]}"
What would be best depends on how you intend to use it. If you just want raw access to the command line arguments, ARGV is the way to go. If you want to access certain pieces after Thor has done some processing for you, one of the first two might be more helpful.
Here's my code with all three options included for accessing the command line arguments from outside the Cli < Thor class. Compliments to Darshan.
#!/usr/bin/env ruby
require 'thor'
$args = {}
class Cli < Thor
attr_reader :a, :b
method_option :add, :type => :string, :desc => 'add servers'
method_option :prod, :type => :string, :desc => 'production stack'
desc "tier <stack folder name> <app | web>", "creates an app or web server tier for the stack"
def tier(a,b)
# store a and b in a global hash
$args[:a] = a
$args[:b] = b
# store a and b in class variables
##a = a
##b = b
end
# getter methods, for access of the class variables from outside the class
def self.get_a
##a
end
def self.get_b
##b
end
end
Cli.start
# three ways now to access the command line arguments from outside the Cli < Thor class
puts "the first argument, from $args[:a], is #{$args[:a]}"
puts "the second argument, from Cli.get_b, is #{Cli.get_b}"
puts "the first argument, from ARGV[1], is #{ARGV[1]}"
Results:
$ ./create.rb tier a b
the first argument, from $args[:a], is a
the second argument, from Cli.get_b, is b
the first argument, from ARGV[1], is a
This is my Ruby code:
require 'thor'
require 'thor/group'
module CLI
class Greet < Thor
desc 'hi', 'Say hi!'
method_option :name, :type => :string, :description => 'Name to greet', :default => 'there'
def hi
puts "Hi, #{options[:name]}!"
end
desc 'bye', 'say bye!'
def bye
puts "Bye!"
end
end
class Root < Thor
register CLI::Greet, 'greet', 'greet [COMMAND]', 'Greet with a command'
end
end
CLI::Root.start
This is the output:
C:\temp>ruby greet.rb help greet
Usage:
greet.rb greet [COMMAND]
Greet with a command
How do I get that to look something like this?
C:\temp>ruby greet.rb help greet
Usage:
greet.rb greet [COMMAND]
--name Name to greet
Greet with a command
You've got two things going on here. First, you've assigned --name to a method, not to the entire CLI::Greet class. So if you use the command:
ruby greet.rb greet help hi
you get
Usage:
greet.rb hi
Options:
[--name=NAME]
# Default: there
Say hi!
Which, yes, is wrong-- it doesn't have the subcommand in the help. There's a bug filed for this in Thor. It, however, is showing the method option properly.
What it seems like you're looking for, however, is a class method. This is a method defined for the entire CLI::Greet class, not just for the #hi method.
You'd do this as such:
require 'thor'
require 'thor/group'
module CLI
class Greet < Thor
desc 'hi', 'Say hi!'
class_option :number, :type => :string, :description => 'Number to call', :default => '555-1212'
method_option :name, :type => :string, :description => 'Name to greet', :default => 'there'
def hi
puts "Hi, #{options[:name]}! Call me at #{options[:number]}"
end
desc 'bye', 'say bye!'
def bye
puts "Bye! Call me at #{options[:number]}"
end
end
class Root < Thor
register CLI::Greet, 'greet', 'greet [COMMAND]', 'Greet with a command'
tasks["greet"].options = CLI::Greet.class_options
end
end
CLI::Root.start
With this, ruby greet.rb help greet returns
Usage:
greet.rb greet [COMMAND]
Options:
[--number=NUMBER]
# Default: 555-1212
Greet with a command
Note there is still a hack needed here: the tasks["greet"].options = CLI::Greet.class_options line in CLI::Root. There's a bug filed for this in Thor, too.
I'm writing something that is a bit like Facebook's shared link preview.
I would like to make it easily extendable for new sites by just dropping in a new file for each new site I want to write a custom parser for. I have the basic idea of the design pattern figured out but don't have enough experience with modules to nail the details. I'm sure there are plenty of examples of something like this in other projects.
The result should be something like this:
> require 'link'
=> true
> Link.new('http://youtube.com/foo').preview
=> {:title => 'Xxx', :description => 'Yyy', :embed => '<zzz/>' }
> Link.new('http://stackoverflow.com/bar').preview
=> {:title => 'Xyz', :description => 'Zyx' }
And the code would be something like this:
#parsers/youtube.rb
module YoutubeParser
url_match /(youtube\.com)|(youtu.be)\//
def preview
get_stuff_using youtube_api
end
end
#parsers/stackoverflow.rb
module SOFParser
url_match /stachoverflow.com\//
def preview
get_stuff
end
end
#link.rb
class Link
def initialize(url)
extend self with the module that has matching regexp
end
end
# url_processor.rb
class UrlProcessor
# registers url handler for given pattern
def self.register_url pattern, &block
#patterns ||= {}
#patterns[pattern] = block
end
def self.process_url url
_, handler = #patterns.find{|p, _| url =~ p}
if handler
handler.call(url)
else
{}
end
end
end
# plugins/so_plugin.rb
class SOPlugin
UrlProcessor.register_url /stackoverflow\.com/ do |url|
{:title => 'foo', :description => 'bar'}
end
end
# plugins/youtube_plugin.rb
class YoutubePlugin
UrlProcessor.register_url /youtube\.com/ do |url|
{:title => 'baz', :description => 'boo'}
end
end
p UrlProcessor.process_url 'http://www.stackoverflow.com/1234'
#=>{:title=>"foo", :description=>"bar"}
p UrlProcessor.process_url 'http://www.youtube.com/1234'
#=>{:title=>"baz", :description=>"boo"}
p UrlProcessor.process_url 'http://www.foobar.com/1234'
#=>{}
You just need to require every .rb from plugins directory.
If you're willing to take this approach you should probably scan the filed for the mathing string and then include the right one.
In the same situation I attempted a different approach. I'm extending the module with new methods, ##registering them so that I won't register two identically named methods. So far it works good, though the project I started is nowhere near leaving the specific domain of one tangled mess of a particular web-site.
This is the main file.
module Onigiri
extend self
##registry ||= {}
class OnigiriHandlerTaken < StandardError
def description
"There was an attempt to override registered handler. This usually indicates a bug in Onigiri."
end
end
def clean(data, *params)
dupe = Onigiri::Document.parse data
params.flatten.each do |method|
dupe = dupe.send(method) if ##registry[method]
end
dupe.to_html
end
class Document < Nokogiri::HTML::DocumentFragment
end
private
def register_handler(name)
unless ##registry[name]
##registry[name] = true
else
raise OnigiriHandlerTaken
end
end
end
And here's the extending file.
# encoding: utf-8
module Onigiri
register_handler :fix_backslash
class Document
def fix_backslash
dupe = dup
attrset = ['src', 'longdesc', 'href', 'action']
dupe.css("[#{attrset.join('], [')}]").each do |target|
attrset.each do |attr|
target[attr] = target[attr].gsub("\\", "/") if target[attr]
end
end
dupe
end
end
end
Another way I see is to use a set of different (but behaviorally indistinguishable) classes with a simple decision making mechanism to call a right one. A simple hash that holds class names and corresponding url_matcher would probably suffice.
Hope this helps.
I am creating a CLI app using thor. Its going well but now I'm stuck with the sub-command feature.
There ain't anything in its github wiki and googled around, but nothing helpful.
So, can someone show or point me out how to implement the subcommand feature?
Check out: http://whatisthor.com/
From that site (edited a bit to save space and highlight subcommand usage):
module GitCLI
class Remote ", "Adds a remote named for the repository at "
option :t, :banner => ""
option :m, :banner => ""
options :f => :boolean, :tags => :boolean, :mirror => :string
def add(name, url)
# implement git remote add
end
desc "rename ", "Rename the remote named to "
def rename(old, new)
end
end
class Git [...]", "Download objects and refs from another repository"
options :all => :boolean, :multiple => :boolean
option :append, :type => :boolean, :aliases => :a
def fetch(respository, *refspec)
# implement git fetch here
end
desc "remote SUBCOMMAND ...ARGS", "manage set of tracked repositories"
subcommand "remote", Remote ### SUBCOMMAND USED HERE...
end
end
hth...
Try something like this (file test.rb):
#!/usr/bin/env ruby
require 'rubygems'
require 'thor'
require 'thor/group' # This is required -- it's not a bug, it's a feature!
class Bar < Thor
desc "baz", "Whatever"
def baz
puts "Hello from Bar"
end
end
class Foo < Thor
desc "go", "Do something"
def go
puts "Hello there!"
end
register Bar, :bar, "bar", "Do something else"
end
if __FILE__ == $0
Foo.start
end
This behaves as follows:
> test.rb
Tasks:
test.rb bar # Do something else
test.rb go # Do something
test.rb help [TASK] # Describe available tasks or one specific task
> test.rb go
Hello there!
> test.rb bar
Tasks:
test.rb baz # Whatever
test.rb help [COMMAND] # Describe subcommands or one specific subcommand
> test.rb bar baz
Hello from Bar
> test.rb baz
Could not find task "baz".
>
(This mostly works as expected, except the help information for "test.rb bar" isn't quite right, IMHO. I think it should say "test.rb bar baz ...", instead of "test.rb baz ...".)
Hope this helps!
I'm trying to figure out how the Thor gem creates a DSL like this (first example from their README)
class App < Thor # [1]
map "-L" => :list # [2]
desc "install APP_NAME", "install one of the available apps" # [3]
method_options :force => :boolean, :alias => :string # [4]
def install(name)
user_alias = options[:alias]
if options.force?
# do something
end
# other code
end
desc "list [SEARCH]", "list all of the available apps, limited by SEARCH"
def list(search="")
# list everything
end
end
Specifically, how does it know which method to map the desc and method_options call to?
desc is pretty easy to implement, the trick is to use Module.method_added:
class DescMethods
def self.desc(m)
#last_message = m
end
def self.method_added(m)
puts "#{m} described as #{#last_message}"
end
end
any class that inherits from DescMethods will have a desc method like Thor. For each method a message will be printed with the method name and description. For example:
class Test < DescMethods
desc 'Hello world'
def test
end
end
when this class is defined the string "test described as Hello world" will be printed.