Install & Compatibility
Where this runs
tested against v4.1.0 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
muslpy 3.10–3.920 runs
installs and imports cleanly · install 0.0s · import 0.264s · 28.5MB
glibcpy 3.10–3.920 runs
installs and imports cleanly · install 2.9s · import 0.253s · 32MB
32MB installed
● package 32MB
Code
Verified usage
Verified import paths — ran on the pinned version, not inferred.
Config
✓ from reno.config import Config
✗ import reno.Config
Configuration is managed via the `Config` object, not directly imported from the top-level package.
Scanner
✓ from reno.scanner import Scanner
✗ import reno.Scanner
Components like Scanner are part of submodules and should be imported directly.
Loader
✓ from reno.loader import Loader
✗ import reno.Loader
The Loader class for managing release notes data resides in its dedicated submodule.
Reno is primarily a command-line interface (CLI) tool for managing release notes within a Git repository. The Python API is mostly for internal use or advanced integrations. A typical workflow involves `reno init` to set up the repository, `reno new` to create new note fragments, and `reno report` or `reno lint` to process them. The quickstart here shows how to import core components programmatically, though direct CLI usage is more common. To use `reno` effectively, consult its command-line documentation.
import os
from reno.config import Config
from reno.main import setup_logging, main
# Simulate command-line arguments and environment
# For a real application, these would come from sys.argv or direct configuration
# os.environ['RENO_DEBUG'] = '1'
# Initialize logging for reno output
setup_logging()
# Example: Setting up a reno repository (usually done once via 'reno init')
# This is a conceptual quickstart; reno is primarily a CLI tool.
# To actually run commands, you'd typically invoke the 'reno' CLI.
# Example for generating release notes (conceptually):
# config = Config()
# config.parse_args(['reno', 'new', 'my-first-note', '--type', 'feature'])
# main(config)
reno --version
Debug
Known issues
gotchaReno stores release notes as individual files in a special directory within your Git repository. Directly editing the generated release notes document (e.g., after `reno report`) will cause inconsistencies with the source notes. Always edit individual note files.fixAlways use `reno new`, `reno edit`, or directly modify the `.rst` or `.yaml` files in the `releasenotes/notes` directory for existing notes. The output of `reno report` is generated, not source-managed.
affects: All versions
breakingOlder versions of `reno` (prior to 3.x) had different command-line arguments and configuration file structures. Upgrading might require adjusting your CI/CD pipelines and `reno.conf` files.fixRefer to the official documentation for the specific version you are upgrading to, paying close attention to the 'Upgrading' or 'Changes' sections. Review `reno.conf` and command usage.
affects: < 3.0.0
gotchaWhen `reno` scans for notes, it may leave open `dulwich.repo.Repo` file handles if not properly closed. This can lead to resource exhaustion in long-running processes or continuous integration environments.fixWhile `reno`'s CLI generally handles this, if you are integrating `reno`'s internal classes like `Scanner` or `Loader` programmatically, ensure you use them within a `with` statement to guarantee proper resource cleanup. E.g., `with scanner.Scanner(conf) as s: ...`.
affects: All versions (if not using context managers)
Errors
Common errors & fixes
reno.exceptions.NoNotesFound: No notes found in repository
This error occurs when `reno` cannot find any release note fragments in the expected location (typically `releasenotes/notes/`) or for the specified branch/version. This can happen if `reno init` was not run, no notes have been created, or the branch specified does not contain any `reno` notes.
fixEnsure `reno init` has been executed in your repository. Create a new note using `reno new <note-name> --type <type>`. Verify that you are on the correct Git branch or that the `reno.conf` settings for `branch` are correct.
Error: unrecognized arguments: --type bugfix
This typically means you are using an older version of `reno` where the `--type` argument for `reno new` might not have been introduced or had a different syntax. Alternatively, there might be a typo in the command.
fixUpdate `reno` to the latest version (`pip install --upgrade reno`). Check the documentation for your specific `reno` version regarding `reno new` command-line arguments. The standard is `reno new <name> --type <category>`.
TypeError: __init__() got an unexpected keyword argument 'encoding'
This error indicates that you are attempting to use the `encoding` configuration option with a version of `reno` that does not support it. The `encoding` option was added in `reno` 3.2.0.
fixUpgrade `reno` to version 3.2.0 or newer: `pip install --upgrade reno`. If upgrading is not an option, remove the `encoding` setting from your `reno.conf` file.
Upgrade
Version history
4.1.0latest on PyPI · released Mar 4, 2024
Audit
Dependencies
dulwichrequiredGit repository interaction
packagingrequiredVersion handling and comparison
pbrrequiredUsed for packaging and version management within OpenStack projects
pyyamlrequiredParsing and managing YAML-formatted configuration and note files