Since we don't want the name of the tool to reflect the fact that
it is using yard internally (this is an implementation detail), rename
the face to `strings`. Now when one wishes to generate documentation,
`puppet strings` will be used rather than `puppet yardoc`.
In order to make the code more readable, separate the tests into
different files for each handler. Additionally, extract the helper
methods into a separate module which may be included as needed.
Update the tests around the host class handler so that they test
several different examples as opposed to just one. Additionally,
refactor the tests so that they are more detailed when it comes to
checking if the Registry is in the correct state after code has been
parsed.
Rework the tests around the 3x function handler. Make them more
verbose by having them them test against multiple examples and by making
the checking of the Registry more details.
Like the 4x function handler tests, the tests around the defined
type handler were not very specific and didn't use multiple examples.
Update the tests so that they do more than just ensure that the right
objects were added to the Registry and cover a few different cases
instead of just one.
Update the spec tests which cover the Puppet 4x function handler
to be more specific and cover different test cases. Prior to this commit,
they would simply check that the right objects had been added to the
Registry for one example. Now, they examine multiple examples and ensure that
the code objects not only exist but that the details about them are what we
would expect for each specific scenario.
Add tests to ensure that the face (puppet yardoc) works from end to
end. In other words, ensure that when given a module, puppet yardoc can
successfully evaluate the .pp and .rb files present in the module and
produce the expected HTML.
Add tests for the remaining two Puppet-specific handlers that were
not tested in the previous commit. Specifically, add tests for the
3.x function handler and the host class handler.
Begin to test the YARD handlers written for the puppet language.
Add basic tests for the defined type and puppet 4 function
handlers. In addition, make changes to the spec helper to make it
easier to work with YARD Registries for testing purposes.
Prior to this commit there was no testing around the pops component.
Since most of the API in the pops component is private, there aren't
very many things to test, so add just a few test cases.
Additionally rename a previous spec file and make some changes to
the Gemfile.
Add spec tests for Puppet face component, mainly around error checking.
Due to the use of `puppet module list`, the behavior of the `modules`
and `server` actions are not very feasible to test via spec testing.
Additionally, make a few minor changes to the gem file, and make a
small change in `check_required_features` to reflect the fact that
this module will no longer support anything earlier than Ruby 1.9.
Prior to this commit there was no Gemfile for this project. Now
a Gemfile has been added so that those developing the project
can take advantage of Bundler.
This patch recurses into any `create_function` block and processes any
`dispactch` blocks contained within. The implementation assumes docstrings will
be provided as a comment block, but this is just a temporary placeholder.
Idealy, the contents of the `dispatch` block would be processed to produce an
`@override` tag for 4.x functions.
All Future Parser functions are documented using a standard YARD comment block.
This commit adds a new code object that watches for `create_function` and
generates a YARD `CodeObject::MethodObject` containing the docstring.
The Puppet Core uses a `.yardopts` file that hides all docstrings that do not
have an API tag. This patch is a hack that allows `puppet yardoc` to extract
documentation for parser functions shipped in the core.
FIXME: This isn't the right way to solve the problem. The right way to solve
the problem is to adjust the Puppet `.yardopts` file to a sane value.
The `namespace_list` helper is used to filter YARD objects in order to populate
search lists. The code was originally derived from the `class_list` helper.
This patch guards against calling `children` on objects that have no children
and removes a recursive call to the old `class_list` method.
This class is functionally equivalent to the ModuleObject class that YARD uses
for Ruby code. Using a new class allows us to gather YARD objects related to
Puppet and separate them from the Ruby bits.
This method has an inverted conditional which means the progress bar still
animates when `--debug` is passed. Not having an easy way to switch the
animation off is a real bummer as it completely hoses the Pry REPL.
Ref. lsegal/yard#783
This handler triggers on all occurrences of `newfunction` and parses the
parameters passed to that method in order to generate documentation. The
implementation is a good experiment in extracting documentation without
evaluating Ruby code. However, the generality of this approach may ultimately
be doomed by the use of metaprogramming in custom Types and Providers.
The default YARD template lumps anything that inherits from `NamespaceObject`
into the "Classes" list in HTML output. This patch alters the list generation
logic so that Namespaces parsed from manifests are listed in a separate
"Puppet Manifests" list.
The Future Parser will return nil if a manifest file contains no statements
(I.E. it is empty or full of comments). Handle these cases and ensure the
`enumerate` method of the YARD parser always returns an Array.
This commit adds the `puppet yardoc server` action which is designed to
mimic `yard server --gems`. This action generates YARD indicies by invoking
`puppet yardoc modules` and then configures `YARD::CLI::Server` to serve the
resulting documentation.
This commit adds the `puppet yardoc modules` action which is designed to
process Puppet Modules in the same way `yard gems` processes Ruby Gems. This
action walks the list of modules generated by `puppet module list` and
generates a YARD index (.yardoc directory) in each module root. This index
contains all the data required to generate documentation using other YARD
tools.
The `YARD::Registry#resolve` method assumes all subclasses of `NamespaceObject`
respond to `inheritance_tree`.
Ref commit d6a4791 for a similar case with `HostClassObject`.
This reverts commit a051319b34.
Added a FIXME note to `defined_type_object.rb` that explains why this patch was
originally created, why it was reverted and what unresolved issues remain.
Puppet Yardoc now generates documentation for defined types in addition to host
classes. The actual change was fairly small, however this patch is quite large
as most of the host class bits were re-architected to inherit from defined
types. Host classes are basically the same as defined types with the addition
of inheritance. Pops also models Host Class using a similar inheritance
relationship.
Re-worked the YARD transformer and handlers to attach parameters to the
resulting code objects. Some architectural debt was incurred in the interests
of producing a working prototype quickly.
When creating an object, YARD will split the object name using `::` and
recursively create proxy namespaces for each component. Unfortunately this
process is optimized for Ruby and somewhat mangles Puppet code as Puppet class
names are not capitalized.
For now, dispense with this behavior by implementing `HostClassObject.new`.
Hailee Kenney