Browse files

Add Sphinx documentation, simplify README and update screenshots. (#230)

  • Loading branch information...
matthewwardrop committed Mar 17, 2018
1 parent f8c33f3 commit 7eecc6a5b13dcffec125fe657e5d9168440f20b4

Large diffs are not rendered by default.

Oops, something went wrong.
@@ -0,0 +1,23 @@
# Minimal makefile for Sphinx documentation
# You can set these variables from the command line.
SPHINXBUILD = sphinx-build
SPHINXPROJ = KnowledgeRepo
BUILDDIR = _build
# Put it first so that "make" without argument is like "make help".
.PHONY: help Makefile
# Catch-all target: route all unknown targets to Sphinx using the new
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
%: Makefile
sphinx-autobuild -b html -z .. "$(SOURCEDIR)" $(SPHINXOPTS) $(BUILDDIR)/html
@@ -0,0 +1,166 @@
# -*- coding: utf-8 -*-
# Configuration file for the Sphinx documentation builder.
# This file does only contain a selection of the most common options. For a
# full list see the documentation:
# -- Path setup --------------------------------------------------------------
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
import os
import sys
sys.path.insert(0, os.path.abspath('..'))
import knowledge_repo
# -- Project information -----------------------------------------------------
project = 'Knowledge Repo'
copyright = '2018, Airbnb and contributors'
author = 'Airbnb and contributors'
# The short X.Y version
version = 'v' + knowledge_repo.__version__.split('_')[0]
# The full version, including alpha/beta/rc tags
release = version
# -- General configuration ---------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
# needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = [
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix(es) of source filenames.
# You can specify multiple suffix as a list of string:
# source_suffix = ['.rst', '.md']
source_suffix = '.rst'
# The master toctree document.
master_doc = 'index'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
# This is also used if you do content translation via gettext catalogs.
# Usually you set "language" from the command line for these cases.
language = None
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
# This pattern also affects html_static_path and html_extra_path .
exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# -- Options for HTML output -------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
import sphinx_rtd_theme
html_theme = "sphinx_rtd_theme"
html_theme_path = [sphinx_rtd_theme.get_html_theme_path()]
# options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
# html_theme_options = {}
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
# Custom sidebar templates, must be a dictionary that maps document names
# to template names.
# The default sidebars (for documents that don't match any pattern) are
# defined by theme itself. Builtin themes are using these templates by
# default: ``['localtoc.html', 'relations.html', 'sourcelink.html',
# 'searchbox.html']``.
# html_sidebars = {}
# -- Options for HTMLHelp output ---------------------------------------------
# Output file base name for HTML help builder.
htmlhelp_basename = 'KnowledgeRepodoc'
# -- Options for LaTeX output ------------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
# 'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
# 'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
# 'preamble': '',
# Latex figure (float) alignment
# 'figure_align': 'htbp',
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
(master_doc, 'KnowledgeRepo.tex', 'Knowledge Repo Documentation',
'Airbnb and contributors', 'manual'),
# -- Options for manual page output ------------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
(master_doc, 'knowledgerepo', 'Knowledge Repo Documentation',
[author], 1)
# -- Options for Texinfo output ----------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
(master_doc, 'KnowledgeRepo', 'Knowledge Repo Documentation',
author, 'KnowledgeRepo', 'One line description of project.',
# -- Extension configuration -------------------------------------------------
@@ -0,0 +1,36 @@
We welcome all manner of contributions, including bug reports, feature
suggestions, documentation improvements, and patches to support new or improved
For developers looking to extend the Knowledge Repo, a few specific common
examples are provided below.
Adding support for new Knowledge Post conversions
Support for conversion of a particular filetype to a knowledge post is added by
writing a new `KnowledgePostConverter` object. Each converter should live in its
own file in `knowledge_repo/converters`. Refer to the implementation for ipynb,
Rmd, and md for more details. If your conversion is site-specific, you can
define these subclasses in `.knowledge_repo_config`, whereupon they will be
picked up by the conversion code.
Adding extra structure and/or verifications to the knowledge post conversion process
When a KnowledgePost is constructed by converting from support filetypes, the
resulting post is then passed through a series of postprocessors (defined in
`knowledge_repo/postprocessors`). This allows one to modify the knowledge post,
upload images to remote storage facilities (such as S3), and/or verify some
additional structure of the knowledge posts. As above, defining or importing
these classes in `` allows for postprocessors to be
used locally.
Something else?
Please don't hesitate to file an issue on our GitHub issue tracker, and we will
get back to you when we can.
Oops, something went wrong.

0 comments on commit 7eecc6a

Please sign in to comment.