lsegal-yard 0.2.3 → 0.2.3.5
Sign up to get free protection for your applications and to get access to all the features.
- data/.yardopts +12 -0
- data/README.markdown +57 -60
- data/Rakefile +6 -2
- data/bin/yri +8 -1
- metadata +6 -6
- data/FAQ.markdown +0 -28
data/.yardopts
ADDED
@@ -0,0 +1,12 @@
|
|
1
|
+
-
|
2
|
+
docs/WHATSNEW.markdown
|
3
|
+
docs/GETTING_STARTED.markdown
|
4
|
+
docs/OVERVIEW.markdown
|
5
|
+
docs/CODE_OBJECTS.markdown
|
6
|
+
docs/TAGS.markdown
|
7
|
+
docs/PARSER.markdown
|
8
|
+
docs/HANDLERS.markdown
|
9
|
+
docs/GENERATORS.markdown
|
10
|
+
docs/FAQ.markdown
|
11
|
+
docs/GLOSSARY.markdown
|
12
|
+
LICENSE
|
data/README.markdown
CHANGED
@@ -1,5 +1,5 @@
|
|
1
|
-
YARD Release 0.2.
|
2
|
-
|
1
|
+
YARD Release 0.2.3.4 (August 7th 2009)
|
2
|
+
=====================================
|
3
3
|
|
4
4
|
**Homepage**: [http://yard.rubyforge.org](http://yard.rubyforge.org)
|
5
5
|
**IRC**: **Join us on IRC in #yard on irc.freenode.net!**
|
@@ -34,45 +34,10 @@ documentation, but provide a much more consistent and usable way to describe
|
|
34
34
|
important information about objects, such as what parameters they take and what types
|
35
35
|
they are expected to be, what type a
method should return, what exceptions it can
|
36
36
|
raise, if it is deprecated, etc.. It also allows information to be better (and more
|
37
|
-
consistently) organized
during the output generation phase.
|
38
|
-
|
39
|
-
|
40
|
-
#### Table 1. Meta-tags and their descriptions
|
41
|
-
|
42
|
-
##### `@param [Types] name Description`
|
43
|
-
Allows for the definition of a method parameter with
optional type information.
|
44
|
-
|
45
|
-
##### `@yieldparam [Types] name Description`
|
46
|
-
Allows for the definition of a method parameter to a yield block with optional
|
47
|
-
type information.
|
48
|
-
|
49
|
-
##### `@yield [paramnames] Description`
|
50
|
-
Allows the developer to document the purpose of a yield block in a method.
|
51
|
-
|
52
|
-
##### `@return [Types] Description`
|
53
|
-
Describes what the method returns with optional type information.
|
54
|
-
|
55
|
-
##### `@deprecated Description`
|
56
|
-
Informs the developer that a method is deprecated and should no
|
57
|
-
longer be used. The description offers the developer an alternative
|
58
|
-
solution or method for the problem.
|
59
|
-
|
60
|
-
##### `@raise [Class] Description`
|
61
|
-
Tells the developer that the method may raise an exception and of what type.
|
62
|
-
|
63
|
-
##### `@see name`
|
64
|
-
References another object, URL, or other for extra information.
|
65
|
-
|
66
|
-
##### `@since number`
|
67
|
-
Lists the version number in which the object first appeared.
|
68
|
-
|
69
|
-
##### `@version number`
|
70
|
-
Lists the current version of the documentation for the object.
|
37
|
+
consistently) organized
during the output generation phase. You can find a list
|
38
|
+
of tags in the {file:
|
71
39
|
|
72
|
-
|
73
|
-
The authors responsible for the module
|
74
|
-
|
75
|
-
You might have noticed the optional "types" declarations for certain tags.
|
40
|
+
YARD also supports an optional "types" declarations for certain tags.
|
76
41
|
This allows the developer to document type signatures for ruby methods and
|
77
42
|
parameters in a non intrusive but helpful and consistent manner. Instead of
|
78
43
|
describing this data in the body of the description, a developer may formally
|
@@ -99,17 +64,17 @@ descriptive.
|
|
99
64
|
|
100
65
|
**3. Custom Constructs and Extensibility of YARD**: Take for instance the example:
|
101
66
|
|
102
|
-
|
103
|
-
|
104
|
-
|
105
|
-
|
106
|
-
|
107
|
-
|
108
|
-
|
109
|
-
|
110
|
-
|
111
|
-
|
112
|
-
|
67
|
+
class A
|
68
|
+
class << self
|
69
|
+
def define_name(name, value)
|
70
|
+
class_eval "def #{name}; #{value.inspect} end"
|
71
|
+
end
|
72
|
+
end
|
73
|
+
|
74
|
+
# Documentation string for this name
|
75
|
+
define_name :publisher, "O'Reilly"
|
76
|
+
end
|
77
|
+
|
113
78
|
This custom declaration provides dynamically generated code that is hard for a
|
114
79
|
documentation tool to properly document without help from the developer. To
|
115
80
|
ease the pains of manually documenting the procedure, YARD can be extended by
|
@@ -147,7 +112,7 @@ simply type `yardoc` in your project root. This will assume your files are
|
|
147
112
|
located in the `lib/` directory. If they are located elsewhere, you can specify
|
148
113
|
paths and globs from the commandline via:
|
149
114
|
|
150
|
-
|
115
|
+
$ yardoc 'lib/**/*.rb' 'app/**/*.rb' ...etc...
|
151
116
|
|
152
117
|
The tool will generate a `.yardoc` file which will store the cached database
|
153
118
|
of your source code and documentation. If you want to re-generate your docs
|
@@ -158,15 +123,26 @@ YARD will by default only document code in your public visibility. You can
|
|
158
123
|
document your protected and private code by adding `--protected` or
|
159
124
|
`--private` to the option switches.
|
160
125
|
|
126
|
+
You can also add extra informative files with the `--files` switch,
|
127
|
+
for example:
|
128
|
+
|
129
|
+
$ yardoc --files FAQ,LICENSE
|
130
|
+
|
131
|
+
Note that the README file is specified with its own `--readme` switch.
|
132
|
+
|
133
|
+
You can also add a `.yardopts` file to your project directory which lists
|
134
|
+
the switches separated by whitespace (newlines or space) to pass to yardoc
|
135
|
+
whenever it is run.
|
136
|
+
|
161
137
|
**2. Rake Task**
|
162
138
|
|
163
139
|
The second most obvious is to generate docs via a Rake task. You can do this by
|
164
140
|
adding the following to your `Rakefile`:
|
165
141
|
|
166
|
-
|
167
|
-
|
168
|
-
|
169
|
-
|
142
|
+
YARD::Rake::YardocTask.new do |t|
|
143
|
+
t.files = ['lib/**/*.rb', OTHER_PATHS] # optional
|
144
|
+
t.options = ['--any', '--extra', '--opts'] # optional
|
145
|
+
end
|
170
146
|
|
171
147
|
both the `files` and `options` settings are optional. `files` will default to
|
172
148
|
`lib/**/*.rb` and `options` will represents any options you might want
|
@@ -174,7 +150,7 @@ to add. Again, a full list of options is available by typing `yardoc --help`
|
|
174
150
|
in a shell. You can also override the options at the Rake command-line with the
|
175
151
|
OPTS environment variable:
|
176
152
|
|
177
|
-
|
153
|
+
$ rake yardoc OPTS='--any --extra --opts'
|
178
154
|
|
179
155
|
**3. `yri` RI Implementation**
|
180
156
|
|
@@ -182,8 +158,8 @@ The yri binary will use the cached .yardoc database to give you quick ri-style
|
|
182
158
|
access to your documentation. It's way faster than ri but currently does not
|
183
159
|
work with the stdlib or core Ruby libraries, only the active project. Example:
|
184
160
|
|
185
|
-
|
186
|
-
|
161
|
+
$ yri YARD::Handlers::Base#register
|
162
|
+
$ yri File::relative_path
|
187
163
|
|
188
164
|
**4. `yard-graph` Graphviz Generator**
|
189
165
|
|
@@ -196,12 +172,33 @@ option to show mixin inclusions. You can output to stdout or a file, or pipe dir
|
|
196
172
|
to `dot`. The same public, protected and private visibility rules apply to yard-graph.
|
197
173
|
More options can be seen by typing `yard-graph --help`, but here is an example:
|
198
174
|
|
199
|
-
|
175
|
+
$ yard-graph --protected --full --dependencies
|
200
176
|
|
201
177
|
|
202
178
|
CHANGELOG
|
203
179
|
---------
|
204
180
|
|
181
|
+
- **July.06.09**: 0.2.3.2 release
|
182
|
+
- Fix Textile hard-break issues
|
183
|
+
- Add description for @see tag to use as link title in HTML docs.
|
184
|
+
- Add --title CLI option to specify a title for HTML doc files.
|
185
|
+
- Add custom.css file that can be overridden with various custom
|
186
|
+
styelsheet declarations. To use this, simply add `default/fulldoc/html/custom.css`
|
187
|
+
inside your code directory and use the `-t` template directory yardoc CLI
|
188
|
+
option to point to that template directory (the dir holding 'default').
|
189
|
+
- Add support in `yardoc` CLI to specify extra files (formerly --files)
|
190
|
+
by appending "- extra files here" after regular source files. Example:
|
191
|
+
|
192
|
+
yardoc --private lib/**/*.rb - FAQ LICENSE
|
193
|
+
|
194
|
+
- **Jun.13.09**: 0.2.3.1 release.
|
195
|
+
- Add a RubyGems 1.3.2+ plugin to generate YARD documentation instead of
|
196
|
+
RDoc. To take advantage of this plugin, set `has_rdoc = 'yard'` in your
|
197
|
+
.gemspec file.
|
198
|
+
|
199
|
+
- **Jun.07.09**: 0.2.3 release. See the {file:WHATSNEW.markdown} file for a
|
200
|
+
list of important new features.
|
201
|
+
|
205
202
|
- **Jun.16.08**: 0.2.2 release. This is the largest changset since yard's
|
206
203
|
conception and involves a complete overhaul of the parser and API to make it
|
207
204
|
more robust and far easier to extend and use for the developer.
|
data/Rakefile
CHANGED
@@ -26,9 +26,13 @@ desc "Run all specs"
|
|
26
26
|
Spec::Rake::SpecTask.new("specs") do |t|
|
27
27
|
$DEBUG = true if ENV['DEBUG']
|
28
28
|
t.spec_opts = ["--format", "specdoc", "--colour"]
|
29
|
+
t.spec_opts += ["--require", File.join(File.dirname(__FILE__), 'spec', 'spec_helper')]
|
29
30
|
t.spec_files = Dir["spec/**/*_spec.rb"].sort
|
31
|
+
t.rcov = true if ENV['RCOV']
|
32
|
+
t.rcov_opts = ['-x', '_spec\.rb$,spec_helper\.rb$']
|
30
33
|
end
|
34
|
+
task :spec => :specs
|
31
35
|
|
32
36
|
YARD::Rake::YardocTask.new do |t|
|
33
|
-
t.
|
34
|
-
end
|
37
|
+
t.after = lambda { `cp -R docs/images/ doc/images/` }
|
38
|
+
end
|
data/bin/yri
CHANGED
@@ -3,11 +3,18 @@ require File.dirname(__FILE__) + '/../lib/yard'
|
|
3
3
|
|
4
4
|
YARD::Registry.load
|
5
5
|
|
6
|
+
if ARGV[0] == '-T' || ARGV[0] == '--no-pager'
|
7
|
+
output = YARD::Serializers::StdoutSerializer.new
|
8
|
+
ARGV.shift
|
9
|
+
else
|
10
|
+
output = YARD::Serializers::ProcessSerializer.new('less')
|
11
|
+
end
|
12
|
+
|
6
13
|
object = YARD::Registry.at(ARGV[0])
|
7
14
|
options = {
|
8
15
|
:format => :text,
|
9
16
|
:template => :default,
|
10
|
-
:serializer =>
|
17
|
+
:serializer => output
|
11
18
|
}
|
12
19
|
|
13
20
|
YARD::Generators::QuickDocGenerator.new(options).generate(object)
|
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: lsegal-yard
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.2.3
|
4
|
+
version: 0.2.3.5
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Loren Segal
|
@@ -9,12 +9,12 @@ autorequire:
|
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
11
|
|
12
|
-
date:
|
12
|
+
date: 2009-08-13 00:00:00 -07:00
|
13
13
|
default_executable:
|
14
14
|
dependencies: []
|
15
15
|
|
16
|
-
description:
|
17
|
-
email: lsegal
|
16
|
+
description: YARD is a documentation generation tool for the Ruby programming language. It enables the user to generate consistent, usable documentation that can be exported to a number of formats very easily, and also supports extending for custom Ruby constructs such as custom class level definitions.
|
17
|
+
email: lsegal@soen.ca
|
18
18
|
executables:
|
19
19
|
- yardoc
|
20
20
|
- yri
|
@@ -25,10 +25,10 @@ extra_rdoc_files: []
|
|
25
25
|
|
26
26
|
files:
|
27
27
|
- LICENSE
|
28
|
-
- FAQ.markdown
|
29
28
|
- README.markdown
|
30
29
|
- Rakefile
|
31
|
-
|
30
|
+
- .yardopts
|
31
|
+
has_rdoc: yard
|
32
32
|
homepage: http://yard.soen.ca
|
33
33
|
post_install_message:
|
34
34
|
rdoc_options: []
|
data/FAQ.markdown
DELETED
@@ -1,28 +0,0 @@
|
|
1
|
-
FAQ
|
2
|
-
===
|
3
|
-
|
4
|
-
1. **So, show me some cool stuff. What can YARD do?**
|
5
|
-
- [Visualize with GraphViz][graphviz] Visualize your classes and methods with GraphViz
|
6
|
-
- [Inline RSpecs][inline-rspecs] In your rspec files, call the following to refer back to and call the inline rspecs: `described_in_docs "String", "camelcase"`
|
7
|
-
- [Inline doc testing][inline-doctest] Use the 'docspec' command line tool to run the above tests. This is similar to [Ruby DocTest][rubdoctest]'s inline irb testing.
|
8
|
-
|
9
|
-
2. **Why did you pick the @-symbol tags for documentation?**
|
10
|
-
|
11
|
-
Java, C++, Python and many other languages have standard documentation tools that use the @tag "standard". This has been extended to the Ruby language, and YARD takes advantage of this common style.
|
12
|
-
|
13
|
-
3. **Can I tweak it to use some other documentation standard?**
|
14
|
-
|
15
|
-
Yes. YARD is flexible enough to have other documentation syntaxes put into use. [TODO: Add information about customization here.]
|
16
|
-
|
17
|
-
4. **Why don't you use ParseTree, or sydparse? Why did you write your own parser?**
|
18
|
-
|
19
|
-
All ruby parsers that we are aware of have two limitations that are unacceptable to a documentation parser:
|
20
|
-
1. They do not put comments into the parse tree.
|
21
|
-
2. They all fail ungracefully on parse errors.
|
22
|
-
|
23
|
-
As a result, YARD uses its own ruby parser that pays particular attention to the comment sections so that all of the information that is needed can be gleened from code and comments alike.
|
24
|
-
|
25
|
-
[graphviz]:http://gnuu.org/2008/02/29/generating-class-diagrams-with-yard-and-graphviz/
|
26
|
-
[inline-rspecs]:http://github.com/lsegal/yard/tree/5b07d706eee6bc0d7f13d9ec1e6e0ab914d3679c/lib/yard/core_ext/string.rb
|
27
|
-
[inline-doctest]:http://github.com/lsegal/yard/tree/master/lib/yard/handlers/base.rb#L350
|
28
|
-
[rubydoctest]:http://github.com/tablatom/rubydoctest
|