Packaging and Distribution
Relevant source files
The following files were used as context for generating this wiki page:
Packaging and distribution in the Rope project encompass the configuration and processes required to build, version, and release the library to the Python ecosystem. The project has transitioned from legacy setup scripts to a modern PEP 517 compliant structure using pyproject.toml as the primary configuration hub.
The system ensures that the library is available across multiple platforms and Python versions (specifically 3.8 to 3.12+), while managing a lean dependency chain. Distribution is primarily handled via PyPI, with support for offline installs through wheel packages.
Sources: pyproject.toml:4-31, README.rst:83-118, CHANGELOG.md:214-216
Build System Configuration
Rope utilizes setuptools as its build backend. The configuration is centralized in pyproject.toml, defining how the package is constructed and what files are included.
Metadata and Requirements
The project specifies core metadata such as the project name, description, and supported Python versions. It maintains a minimal dependency on pytoolconfig.
| Field | Value/Description |
|---|---|
| Name | rope |
| Version | 1.14.0 |
| Build Backend | setuptools.build_meta |
| Minimum Python | >=3.8 |
| Dependencies | pytoolconfig[global] >= 1.2.2 |
Sources: pyproject.toml:1-31, pyproject.toml:98-101
Package Structure
Rope includes several subpackages in its distribution, ensuring that core refactoring logic, base utilities, and contribution modules (like autoimport) are bundled.
The diagram shows the package hierarchy defined for distribution.
Sources: pyproject.toml:68-81
Versioning Mechanism
The project employs a dual-strategy for version retrieval to ensure the version string is available both in installed environments and development checkouts.
Dynamic Version Retrieval
The rope/__init__.py file attempts to retrieve the version using importlib.metadata. If the package is not installed (e.g., during local development), it falls back to a regex-based parser that reads the version directly from pyproject.toml.
try:
VERSION = importlib.metadata.version("rope")
except importlib.metadata.PackageNotFoundError:
def get_fallback_version():
import pathlib
import re
pyproject = (
pathlib.Path(__file__).resolve().parent.parent / "pyproject.toml"
).read_text()
version = re.search("version.*=.*'(.*)'", pyproject)
return version.group(1) if version else None
VERSION = get_fallback_version()
Sources: rope/init.py:5-18
Dependency Groups
Rope defines optional dependencies to facilitate various development and maintenance tasks without bloating the core installation.
| Group | Dependencies | Purpose |
|---|---|---|
| doc | sphinx, sphinx-rtd-theme, etc. | Building documentation |
| dev | pytest, pytest-cov, build, pre-commit | Local development and testing |
| release | toml, twine, pip-tools | Packaging and PyPI uploads |
Sources: pyproject.toml:44-67
Distribution Channels and Formats
Rope is distributed as both Source Distributions (sdist) and Wheels.
Platforms and Compatibility
The library is marked as Operating System :: OS Independent and supports multiple environments:
- X11 Applications
- Win32 (MS Windows)
- MacOS X
Sources: pyproject.toml:10-16
Release History and Artifacts
Starting from version 0.21.1, the project began publishing wheel packages specifically to enable offline installs. The project also maintains presence on various distro/package managers, tracked via Repology.
Sources: CHANGELOG.md:214-216, README.rst:111-118
Integration Fixtures
For testing purposes, the project includes specialized package fixtures like external_fixturepkg. These are used to validate Rope's behavior against different build systems (e.g., flit-core).
The diagram illustrates how external fixture packages are isolated during testing to validate build-system compatibility.
Sources: CHANGELOG.md:18, ropetest-package-fixtures/external_fixturepkg/pyproject.toml:1-4
The packaging architecture of Rope has evolved to support modern standards, moving from setup.py to pyproject.toml in version 1.2.0. This change streamlined the build process and consolidated metadata, ensuring the library remains compatible with current Python packaging tools.
Sources: CHANGELOG.md:183-186