Giter Club home page Giter Club logo

indexer's Introduction

INDEXER

Enable Your Project's Metadata

Build Status Gem Version

Indexer provides projects with a universal metadata format.

Indexer defines a canonical project metadata specification which is both detailed and strict. The strictness of the specification makes the format simple enough for developers to use without an intermediate API. Although Indexer also provides a convenience API for working with the specification and its data more loosely when suitable to the usecase. Indexer also specifies a standard location for canonized metadata to be kept, in a .index file.

Indexer provides a tool to import metadata from external sources. Indexer can handle a variety of metadata source formats, including YAML, HTML Microformats and Ruby DSL scripts.

  • YAML-based format for universal accessibility.
  • Platform and programming language agnostic.
  • Canonical specification provides idempotent access.
  • Convenient Ruby API available.
  • Supports custom metadata fields.

Indexer is a Ruby application, so as long as you have Ruby installed, it is easy to install Indexer via RubyGems.

$ gem install indexer

Indexer is capable of generating a canonical .index file from a variety of sources. Being so flexible, exactly how a developer decides to store a project's metadata is a largely a matter of taste. But in general there are four overall approaches:

  1. Specify the metadata in one or more static files, typically a single YAML file.
  2. Specify the metadata using microformats in a project's README file.
  3. Construct the metadata via a Ruby DSL, customizing the generation in any way.

The first approach is a great option in the it is the easiest. One can quickly put together a YAML document covering a project's metadata. Since Indexer is very flexible in it's parsing of the YAML, it really is a quick and user-friendly way to go. Typically this file will be called Index.yml, but there is no name requirement. In fact, Indexer will also let you split the metadata up over multiple files, and can even go as far as using a file store, which is a directory of files, one for each field.

The second choice is, in many respects, the nicest because it does not require any additional files be added to a project and it helps to ensure a good README file. On the downside, it may require some HTML be hand-coded into the README. If your README's markup format has a sexy syntax for microformats, this approach rocks. Otherwise, another approach is probably the better choice.

The last approach provides maximum flexibility. Using the Ruby DSL one can literally script the metadata, which means it can come from anywhere at all. For example, you might want to pull the project's version from the lib/project/version.rb file, i.e. Bundler style. The DSL is as intuitive and as flexible as using plain YAML, so it's nearly as easy to take this approach. By convention this file is called Indexfile or Index.rb, but it too can be any file path one prefers.

On the Indexer wiki you can find detailed tutorials on a variety of setups, along with their pros and cons and various tip and tricks.

As an example of getting started, lets say we want to customize our index metadata via a YAML file, but we want to keep the version information is a separate VERSION file. That's a common layout so Indexer is designed to handle it out of the box. First create the VERSION file.

$ echo '0.1.0' > VERSION

Next we need our YAML file. Indexer makes out life easier by offering us some template generation for common approaches. In this case we use the -g/--generate command option, specifying that we want an Index.yml file.

$ index --generate Index.yml

Now we can edit the Index.yaml file to suite our project.

$ vim Index.yml

Once we have the source files setup, its easy to build the canonical .index file using the index command. We simply issue the index command with the -u/--using command option:

$ index --using VERSION Index.yml

Indexer will utilize both sources and create the .index file.

Over time project metadata tends to evolve and change. To keep the canonical .index file up to date simply call the index command without any options.

$ index

By default the .index file will not be updated if it has a modification time newer than its source files. If need be, use the -f/--force option to override this.

That's the quick "one two" of getting started with Indexer. For more information, see the Wiki, API documentation, QED specifications and the Manpages.

Indexer is copyrighted open-source software.

© 2012 Rubyworks

It can be modified and redistributed in accordance with the terms of the BSD-2-Clause license.

indexer's People

Contributors

trans avatar postmodern avatar

Stargazers

Sahal avatar

Watchers

James Cloos avatar  avatar

Forkers

sandnerd

indexer's Issues

Better Importer Design

Currently the Importer uses modules and inheritance chain to apply different types of importers in order (via super call). This is kind of a weird way to do it. A more proper approach would probably be to use a class for each type of importer (or a at least a self extend module) and register them in proper order. Then the Importer would just run through the list until one succeeds.

Improve handling of optional requirements in gemspec

When generating a gem, make sure a dependency in the optional group is not added to the gemspec.

Not sure how to handle the case when a requirement is both an optional runtime dependency and a development dependency.

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.