Skip to content

Commit

Permalink
Docs: Update contributing documentation (langchain-ai#17557)
Browse files Browse the repository at this point in the history
This PR adds more details about how to contribute to documentation.
  • Loading branch information
eyurtsev authored and al1p-R committed Feb 27, 2024
1 parent 1da2760 commit 1995e52
Showing 1 changed file with 119 additions and 11 deletions.
130 changes: 119 additions & 11 deletions docs/docs/contributing/documentation.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -3,24 +3,68 @@ sidebar_position: 3
---
# Contribute Documentation

The docs directory contains Documentation and API Reference.
LangChain documentation consists of two components:

Documentation is built using [Quarto](https://quarto.org) and [Docusaurus 2](https://docusaurus.io/).
1. Main Documentation: Hosted at [python.langchain.com](https://python.langchain.com/),
this comprehensive resource serves as the primary user-facing documentation.
It covers a wide array of topics, including tutorials, use cases, integrations,
and more, offering extensive guidance on building with LangChain.
The content for this documentation lives in the `/docs` directory of the monorepo.
2. In-code Documentation: This is documentation of the codebase itself, which is also
used to generate the externally facing [API Reference](https://api.python.langchain.com/en/latest/langchain_api_reference.html).
The content for the API reference is autogenerated by scanning the docstrings in the codebase. For this reason we ask that
developers document their code well.

API Reference are largely autogenerated by [sphinx](https://www.sphinx-doc.org/en/master/) from the code and are hosted by [Read the Docs](https://readthedocs.org/).
For that reason, we ask that you add good documentation to all classes and methods.
The main documentation is built using [Quarto](https://quarto.org) and [Docusaurus 2](https://docusaurus.io/).

Similar to linting, we recognize documentation can be annoying. If you do not want to do it, please contact a project maintainer, and they can help you with it. We do not want this to be a blocker for good code getting contributed.
The `API Reference` is largely autogenerated by [sphinx](https://www.sphinx-doc.org/en/master/)
from the code and is hosted by [Read the Docs](https://readthedocs.org/).

## Build Documentation Locally
We appreciate all contributions to the documentation, whether it be fixing a typo,
adding a new tutorial or example and whether it be in the main documentation or the API Reference.

Similar to linting, we recognize documentation can be annoying. If you do not want
to do it, please contact a project maintainer, and they can help you with it. We do not want this to be a blocker for good code getting contributed.

## 📜 Main Documentation

The content for the main documentation is located in the `/docs` directory of the monorepo.

The documentation is written using a combination of ipython notebooks (`.ipynb` files)
and markdown (`.mdx` files). The notebooks are converted to markdown
using [Quarto](https://quarto.org) and then built using [Docusaurus 2](https://docusaurus.io/).

Feel free to make contributions to the main documentation! 🥰

After modifying the documentation:

1. Run the linting and formatting commands (see below) to ensure that the documentation is well-formatted and free of errors.
2. Optionally build the documentation locally to verify that the changes look good.
3. Make a pull request with the changes.
4. You can preview and verify that the changes are what you wanted by clicking the `View deployment` or `Visit Preview` buttons on the pull request `Conversation` page. This will take you to a preview of the documentation changes.

## ⚒️ Linting and Building Documentation Locally

After writing up the documentation, you may want to lint and build the documentation
locally to ensure that it looks good and is free of errors.

If you're unable to build it locally that's okay as well, as you will be able to
see a preview of the documentation on the pull request page.

### Install dependencies

- [Quarto](https://quarto.org) - package that converts Jupyter notebooks (`.ipynb` files) into mdx files for serving in Docusaurus.
- `poetry install --with lint,docs --no-root` from the monorepo root.
- [Quarto](https://quarto.org) - package that converts Jupyter notebooks (`.ipynb` files) into mdx files for serving in Docusaurus. [Download link](https://quarto.org/docs/download/).

From the **monorepo root**, run the following command to install the dependencies:

```bash
poetry install --with lint,docs --no-root
````

### Building

The code that builds the documentation is located in the `/docs` directory of the monorepo.

In the following commands, the prefix `api_` indicates that those are operations for the API Reference.

Before building the documentation, it is always a good idea to clean the build directory:
Expand All @@ -46,7 +90,7 @@ make api_docs_linkcheck

### Linting and Formatting

The docs are linted from the monorepo root. To lint the docs, run the following from there:
The Main Documentation is linted from the **monorepo root**. To lint the main documentation, run the following from there:

```bash
make lint
Expand All @@ -56,9 +100,73 @@ If you have formatting-related errors, you can fix them automatically with:

```bash
make format
```
```

## ⌨️ In-code Documentation

The in-code documentation is largely autogenerated by [sphinx](https://www.sphinx-doc.org/en/master/) from the code and is hosted by [Read the Docs](https://readthedocs.org/).

For the API reference to be useful, the codebase must be well-documented. This means that all functions, classes, and methods should have a docstring that explains what they do, what the arguments are, and what the return value is. This is a good practice in general, but it is especially important for LangChain because the API reference is the primary resource for developers to understand how to use the codebase.

We generally follow the [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings) for docstrings.

Here is an example of a well-documented function:

```python
def my_function(arg1: int, arg2: str) -> float:
"""This is a short description of the function. (It should be a single sentence.)
This is a longer description of the function. It should explain what
the function does, what the arguments are, and what the return value is.
It should wrap at 88 characters.
Examples:
This is a section for examples of how to use the function.
.. code-block:: python
my_function(1, "hello")
Args:
arg1: This is a description of arg1. We do not need to specify the type since
it is already specified in the function signature.
arg2: This is a description of arg2.
Returns:
This is a description of the return value.
"""
return 3.14
```

### Linting and Formatting

The in-code documentation is linted from the directories belonging to the packages
being documented.

For example, if you're working on the `langchain-community` package, you would change
the working directory to the `langchain-community` directory:
```bash
cd [root]/libs/langchain-community
```
Set up a virtual environment for the package if you haven't done so already.

Install the dependencies for the package.

```bash
poetry install --with lint
```

Then you can run the following commands to lint and format the in-code documentation:

```bash
make format
make lint
```

## Verify Documentation changes
## Verify Documentation Changes

After pushing documentation changes to the repository, you can preview and verify that the changes are
what you wanted by clicking the `View deployment` or `Visit Preview` buttons on the pull request `Conversation` page.
Expand Down

0 comments on commit 1995e52

Please sign in to comment.