### Entry Point Declaration (setup.cfg)

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Example of declaring a custom method as an entry point in a setup.cfg file for distribution.

```ini
[options.entry_points]
versioningit.vcs =
    foobar = mypackage.vcs:foobar_vcs
```

--------------------------------

### Install versioningit with pip

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

Install versioningit and its dependencies using pip. This is typically done for development environments.

```shell
python3 -m pip install versioningit
```

--------------------------------

### Entry Point Declaration (pyproject.toml)

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Example of declaring a custom method as an entry point in a pyproject.toml file for distribution.

```toml
[project.entry-points."versioningit.vcs"]
foobar = "mypackage.vcs:foobar_vcs"
```

--------------------------------

### Minimal versioningit configuration

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

Add an empty [tool.versioningit] table to pyproject.toml for basic setup.

```toml
[tool.versioningit]
```

--------------------------------

### Setuptools Configuration via setup.py

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Configure setuptools to use versioningit's custom command classes by passing versioningit.get_cmdclasses() to the 'cmdclass' argument of setup().

```python
from setuptools import setup
from versioningit import get_cmdclasses

setup(
    cmdclass=get_cmdclasses(),
    # Other arguments go here
)
```

--------------------------------

### Example TOML Configuration for Custom VCS Method

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

This TOML snippet shows how to configure versioningit to use a custom VCS method located in a specific module and directory. It also specifies parameters to be passed to the custom method.

```toml
[tool.versioningit.vcs]
method = { module = "ving_methods", value = "my_vcs", module-dir = "tools" }
tag-dir = "tags"
annotated-only = true
```

--------------------------------

### Using a Custom Method (pyproject.toml)

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Example of how a package developer would specify the use of a custom method in their pyproject.toml.

```toml
[tool.versioningit.vcs]
method = "foobar"
# Parameters go here
```

--------------------------------

### Default Regex for 'onbuild' Replacement

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

The default regex used by the 'onbuild' method to find the version line in a file. It looks for a line starting with '__version__ = '.

```regex
^\s*__version__\s*=\s*(?P<version>.*)
```

--------------------------------

### Get Package Version with importlib.metadata

Source: https://github.com/jwodder/versioningit/blob/master/docs/runtime-version.md

Use this method to retrieve your package's version directly. Requires Python 3.8 or later.

```python
from importlib.metadata import version

__version__ = version("mypackage")
```

--------------------------------

### Get Package Version with importlib-metadata Backport

Source: https://github.com/jwodder/versioningit/blob/master/docs/runtime-version.md

Use this method to support older Python versions (prior to 3.8) by using the importlib-metadata backport. Ensure 'importlib-metadata; python_version < "3.8"' is in your install_requires.

```python
import sys

if sys.version_info >= (3, 8):
    from importlib.metadata import version
else:
    from importlib_metadata import version

__version__ = version("mypackage")
```

--------------------------------

### Setuptools Configuration via pyproject.toml

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Configure setuptools to use versioningit's custom command classes by adding a [tool.setuptools.cmdclass] table to pyproject.toml.

```toml
[tool.setuptools.cmdclass]
build_py = "versioningit.cmdclass.build_py"
sdist = "versioningit.cmdclass.sdist"
```

--------------------------------

### Configure build-system.requires for Setuptools

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

Specify versioningit in the build-system.requires for Setuptools projects within pyproject.toml.

```toml
[build-system]
requires = [
    "setuptools",
    "versioningit",
]
build-backend = "setuptools.build_meta"
```

--------------------------------

### Setuptools Configuration via setup.cfg

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Configure setuptools to use versioningit's custom command classes by adding 'cmdclass' to the [options] table in setup.cfg.

```ini
[options]
cmdclass =
    sdist = versioningit.cmdclass.sdist
    build_py = versioningit.cmdclass.build_py
```

--------------------------------

### Basic versioningit Command

Source: https://github.com/jwodder/versioningit/blob/master/docs/command.md

Run the versioningit command to display the version of a project. By default, it operates on the project in the current directory.

```bash
versioningit [<options>] [<project-dir>]
```

--------------------------------

### Configuring setuptools cmdclass with Versioningit

Source: https://github.com/jwodder/versioningit/blob/master/docs/api.md

Use these entries in your setup.cfg to integrate Versioningit's sdist and build_py command classes with setuptools. This ensures the 'onbuild' step is executed during package building.

```ini
[options]
cmdclass =
    # Right!
    sdist = versioningit.cmdclass.sdist
    build_py = versioningit.cmdclass.build_py

[options]
cmdclass =
    # Wrong!
    sdist = versioningit.sdist
    build_py = versioningit.build_py
```

--------------------------------

### Equivalent Versioningit Configurations in Hatch

Source: https://github.com/jwodder/versioningit/blob/master/docs/hatch.md

Demonstrates two equivalent ways to configure versioningit with Hatch: using the [tool.versioningit] table or directly within the [tool.hatch.version] table. Using [tool.hatch.version] is preferred when possible.

```toml
# Using [tool.versioningit]:
[tool.hatch.version]
source = "versioningit"

[tool.versioningit]
default-version = "0.0.0+unknown"

[tool.versioningit.format]
distance = "{next_version}.dev{distance}+{vcs}{rev}"
dirty = "{version}+dirty"
distance-dirty = "{next_version}.dev{distance}+{vcs}{rev}.dirty"

```

```toml
# Using [tool.hatch.version]:
[tool.hatch.version]
source = "versioningit"
default-version = "0.0.0+unknown"

[tool.hatch.version.format]
distance = "{next_version}.dev{distance}+{vcs}{rev}"
dirty = "{version}+dirty"
distance-dirty = "{next_version}.dev{distance}+{vcs}{rev}.dirty"

```

--------------------------------

### Loading Versioningit configuration from pyproject.toml

Source: https://github.com/jwodder/versioningit/blob/master/docs/api.md

Demonstrates how to read and parse the Versioningit configuration directly from a pyproject.toml file using the 'tomli' library in Python. This configuration can then be passed to Versioningit functions.

```python
import tomli

with open("pyproject.toml", "rb") as fp:
    config = tomli.load(fp)["tool"]["versioningit"]
```

--------------------------------

### setuptools_scm Inspired Format Configuration

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

This configuration is inspired by setuptools_scm. It uses 'smallest' for the next version method and defines formats for distance, dirty, and distance-dirty states.

```toml
[tool.versioningit.next-version]
method = "smallest"

[tool.versioningit.format]
distance = "{next_version}.dev{distance}+{vcs}{rev}"
# Example formatted version: 1.2.4.dev42+ge174a1f

dirty = "{base_version}+d{build_date:%Y%m%d}"
# Example formatted version: 1.2.3+d20230922

distance-dirty = "{next_version}.dev{distance}+{vcs}{rev}.d{build_date:%Y%m%d}"
# Example formatted version: 1.2.4.dev42+ge174a1f.d20230922
```

--------------------------------

### Write Version to File

Source: https://github.com/jwodder/versioningit/blob/master/docs/command.md

Use the -w or --write option to write the project's version to a file, as configured in the [tool.versioningit.write] subtable.

```bash
versioningit -w
```

--------------------------------

### Default Format Parameters for the 'format' Step

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

These are the default parameters for the 'format' step in versioningit. They define how the version string is constructed based on different repository states.

```toml
[tool.versioningit.format]
distance = "{base_version}.post{distance}+{vcs}{rev}"
dirty = "{base_version}+d{build_date:%Y%m%d}"
distance-dirty = "{base_version}.post{distance}+{vcs}{rev}.d{build_date:%Y%m%d}"
```

--------------------------------

### Configure the Versioningit Onbuild Hook in Hatch

Source: https://github.com/jwodder/versioningit/blob/master/docs/hatch.md

Configure the 'onbuild' step for versioningit within the [tool.hatch.build.hooks.versioningit-onbuild] table. This is the only configuration needed to enable the 'onbuild' step.

```toml
[tool.hatch.build.hooks.versioningit-onbuild]

```

--------------------------------

### Write Version to a Text File

Source: https://github.com/jwodder/versioningit/blob/master/docs/runtime-version.md

Configure versioningit to write the project version to a plain text file within your package.

```toml
[tool.versioningit.write]
file = "src/mypackage/VERSION"
```

--------------------------------

### Configure hatchling build system

Source: https://github.com/jwodder/versioningit/blob/master/docs/index.md

Specify versioningit in the build-system.requires for hatchling in pyproject.toml, along with Hatch-specific version configuration.

```toml
[build-system]
requires = [
    "hatchling",
    "versioningit",
]
build-backend = "hatchling.build"

[tool.hatch.version]
source = "versioningit"
```

--------------------------------

### Set Versioningit as the Version Source

Source: https://github.com/jwodder/versioningit/blob/master/docs/hatch.md

Configure Hatch to use versioningit as the source for the project's version.

```toml
[tool.hatch.version]
source = "versioningit"

```

--------------------------------

### Configure build-system.requires for Hatch

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

Specify versioningit in the build-system.requires for Hatch projects within pyproject.toml.

```toml
[build-system]
requires = [
    "hatchling",
    "versioningit",
]
build-backend = "hatchling.build"
```

--------------------------------

### versioningit.cmdclass.sdist

Source: https://github.com/jwodder/versioningit/blob/master/docs/api.md

A custom subclass of `setuptools.command.sdist.sdist` that runs the `onbuild` step when building an sdist. This class can be used in the `[options]cmdclass` field in `setup.cfg`.

```APIDOC
## class versioningit.cmdclass.sdist

### Description
A custom subclass of `setuptools.command.sdist.sdist` that runs the `onbuild` step when building an sdist. This class is equivalent to `get_cmdclasses()["sdist"]`, except that it can also be used in the `[options]cmdclass` field in `setup.cfg`.

#### Versionadded
Added in version 2.2.0.

### Usage
```ini
[options]
cmdclass =
    sdist = versioningit.cmdclass.sdist
```
```

--------------------------------

### Import Version from _version.py

Source: https://github.com/jwodder/versioningit/blob/master/docs/runtime-version.md

Import the __version__ variable from the generated _version.py file into your package's __init__.py.

```python
from ._version import __version__
```

--------------------------------

### Passing Explicit Configuration

Source: https://github.com/jwodder/versioningit/blob/master/docs/api.md

Functions and methods that normally read configuration from `versioningit.toml` or `pyproject.toml` can instead be passed a `config` argument (a dictionary) to specify the configuration directly, ignoring configuration files.

```APIDOC
## Passing Explicit Configuration

### Description
Functions & methods that take a path to a project directory normally read the project’s configuration from the `versioningit.toml` or `pyproject.toml` file therein. However, they can also be passed a `config` argument to take the configuration from instead, in which case any configuration files will be ignored and need not even exist.

A `config` argument must be a `dict` whose structure mirrors the structure of the `[tool.versioningit]` table in `pyproject.toml`.

### Example Configuration Structure

**TOML:**
```toml
[tool.versioningit.vcs]
method = "git"
match = ["v*"]

[tool.versioningit.next-version]
method = { module = "setup", value = "my_next_version" }

[tool.versioningit.format]
distance = "{next_version}.dev{distance}+{vcs}{rev}"
dirty = "{base_version}+dirty"
distance-dirty = "{next_version}.dev{distance}+{vcs}{rev}.dirty"
```

**Python Dict:**
```python
{
    "vcs": {
        "method": "git",
        "match": ["v*"],
    },
    "next-version": {
        "method": {
            "module": "setup",
            "value": "my_next_version",
        },
    },
    "format": {
        "distance": "{next_version}.dev{distance}+{vcs}{rev}",
        "dirty": "{base_version}+dirty",
        "distance-dirty": "{next_version}.dev{distance}+{vcs}{rev}.dirty",
    },
}
```

### Alternative Method Specification
When passing `versioningit` configuration as a `config` argument, an alternative way to specify methods becomes available: in place of a method specification, one can pass a callable object directly.
```

--------------------------------

### Write Version to a Python File

Source: https://github.com/jwodder/versioningit/blob/master/docs/runtime-version.md

Configure versioningit to write the project version to a Python file within your package. This file can then be imported.

```toml
[tool.versioningit.write]
file = "src/mypackage/_version.py"
```

--------------------------------

### Configure Git Archive Versioning with Match and Exclude

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Use 'describe-subst' to specify patterns for matching and excluding tags when creating Git archives. This ensures consistent version determination from archives.

```toml
# Match 'v*' tags:
describe-subst = "$Format:%(describe:match=v*)$"

# Match 'v*' and 'r*' tags:
describe-subst = "$Format:%(describe:match=v*,match=r*)$"

# Match 'v*' tags, exclude '*-final' tags:
describe-subst = "$Format:%(describe:match=v*,exclude=*-final)$"
```

--------------------------------

### Display Next Release Version

Source: https://github.com/jwodder/versioningit/blob/master/docs/command.md

Use the --next-version option to show the calculated next release version instead of the current version.

```bash
versioningit --next-version
```

--------------------------------

### Show Error Traceback

Source: https://github.com/jwodder/versioningit/blob/master/docs/command.md

Enable the --traceback option to display the full error traceback for any library errors encountered.

```bash
versioningit --traceback
```

--------------------------------

### Default versioningit format configuration

Source: https://github.com/jwodder/versioningit/blob/master/docs/index.md

This TOML snippet shows the default format configuration for versioningit, including templates for distance, dirty, and distance-dirty states.

```toml
[tool.versioningit.format]

# Format used when there have been commits since the most recent tag:
distance = "{base_version}.post{distance}+{vcs}{rev}"
# Example formatted version: 1.2.3.post42+ge174a1f

# Format used when there are uncommitted changes:
dirty = "{base_version}+d{build_date:%Y%m%d}"
# Example formatted version: 1.2.3+d20230922

# Format used when there are both commits and uncommitted changes:
distance-dirty = "{base_version}.post{distance}+{vcs}{rev}.d{build_date:%Y%m%d}"
```

--------------------------------

### Specify Git VCS Method with Parameters

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Configures the 'vcs' step to use the 'git' method with specific tag matching and default tag settings.

```toml
[tool.versioningit.vcs]
method = "git"
match = ["v*"]
default-tag = "1.0.0"
```

--------------------------------

### Setting a Default Version in Versioningit

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Configure a default version for your package in Versioningit. This version will be used if any errors occur during the version calculation process.

```toml
[tool.versioningit]
default-version = "0.1.0.post0.dev1"

```

--------------------------------

### versioningit.cmdclass.build_py

Source: https://github.com/jwodder/versioningit/blob/master/docs/api.md

A custom subclass of `setuptools.command.build_py.build_py` that runs the `onbuild` step when building a wheel. This class can be used in the `[options]cmdclass` field in `setup.cfg`.

```APIDOC
## class versioningit.cmdclass.build_py

### Description
A custom subclass of `setuptools.command.build_py.build_py` that runs the `onbuild` step when building a wheel. This class is equivalent to `get_cmdclasses()["build_py"]`, except that it can also be used in the `[options]cmdclass` field in `setup.cfg`.

#### Versionadded
Added in version 2.2.0.

### Usage
```ini
[options]
cmdclass =
    build_py = versioningit.cmdclass.build_py
```
```

--------------------------------

### Python dictionary equivalent of TOML configuration

Source: https://github.com/jwodder/versioningit/blob/master/docs/api.md

This Python dictionary represents the structure of Versioningit's configuration as it would appear in pyproject.toml. It can be passed directly to Versioningit functions via the 'config' argument, bypassing file reading.

```python
{
    "vcs": {
        "method": "git",
        "match": ["v*"],
    },
    "next-version": {
        "method": {
            "module": "setup",
            "value": "my_next_version",
        },
    },
    "format": {
        "distance": "{next_version}.dev{distance}+{vcs}{rev}",
        "dirty": "{base_version}+dirty",
        "distance-dirty": "{next_version}.dev{distance}+{vcs}{rev}.dirty",
    },
}
```

--------------------------------

### Enable dynamic version in pyproject.toml

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

Set project.dynamic = ["version"] in pyproject.toml when specifying project metadata to enable versioningit.

```toml
project.dynamic = ["version"]
```

--------------------------------

### vcversioner Inspired Format Configuration

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

This configuration is inspired by vcversioner. It simplifies the version format, primarily using the base version for dirty states and appending post and VCS information for distance states.

```toml
[tool.versioningit.format]
distance = "{base_version}.post{distance}"
# Example formatted version: 1.2.3.post42

dirty = "{base_version}"
# Example formatted version: 1.2.3

distance-dirty = "{base_version}.post{distance}"
# Example formatted version: 1.2.3.post42
```

--------------------------------

### Specify Method Without Parameters

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Shows how to replace a subtable with just the method specification when no parameters are needed.

```toml
[tool.versioningit]
vcs = "git"
next-version = { module = "mypackage.module", value = "my_next_version" }
```

--------------------------------

### Configure Hatch version source

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

Set the version source to 'versioningit' in pyproject.toml when using Hatch.

```toml
[tool.hatch.version]
source = "versioningit"
```

--------------------------------

### Default Versioningit Format Configuration

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

This is the default format configuration for Versioningit. It defines how versions are formatted when there are commits since the last tag, when there are uncommitted changes, or when both conditions are met.

```toml
[tool.versioningit.format]
# Format used when there have been commits since the most recent tag:
distance = "{base_version}.post{distance}+{vcs}{rev}"
# Example formatted version: 1.2.3.post42+ge174a1f

# Format used when there are uncommitted changes:
dirty = "{base_version}+d{build_date:%Y%m%d}"
# Example formatted version: 1.2.3+d20230922

# Format used when there are both commits and uncommitted changes:
distance-dirty = "{base_version}.post{distance}+{vcs}{rev}.d{build_date:%Y%m%d}"
# Example formatted version: 1.2.3.post42+ge174a1f.d20230922
```

--------------------------------

### versioneer Inspired Format Configuration

Source: https://github.com/jwodder/versioningit/blob/master/README.rst

This configuration is inspired by versioneer. It defines formats for distance and dirty states, including the distance in the version string.

```toml
[tool.versioningit.format]
distance = "{base_version}+{distance}.{vcs}{rev}"
# Example formatted version: 1.2.3+42.ge174a1f

dirty = "{base_version}+{distance}.{vcs}{rev}.dirty"
# Example formatted version: 1.2.3+42.ge174a1f.dirty

distance-dirty = "{base_version}+{distance}.{vcs}{rev}.dirty"
# Example formatted version: 1.2.3+42.ge174a1f.dirty
```

--------------------------------

### Add Versioningit to Build Requirements

Source: https://github.com/jwodder/versioningit/blob/master/docs/hatch.md

Include versioningit in your project's build requirements in pyproject.toml.

```toml
[build-system]
requires = ["hatchling", "versioningit"]
build-backend = "hatchling.build"

```

--------------------------------

### Configure Git Archive Versioning with Tag Honor and Exclude

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Configure 'describe-subst' to honor all tags or exclude specific patterns like 'rc' tags when determining versions from Git archives.

```toml
# Honor all tags:
describe-subst = "$Format:%(describe:tags)$"

# Honor all tags, exclude '*rc' tags:
describe-subst = "$Format:%(describe:tags,exclude=*rc)$"
```

--------------------------------

### Declare Dynamic Versioning in Project Metadata

Source: https://github.com/jwodder/versioningit/blob/master/docs/hatch.md

Tell Hatch to use a dynamic source for the project version by including 'version' in the project.dynamic key. Ensure the 'version' key is not set directly.

```toml
[project]
name = "your-project-name"
dynamic = ["version"]
# The rest of your project metadata follows after.

# Do not set the `version` key in [project].  If it's currently set,
# remove it.

```

--------------------------------

### Default Template for .py files

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

The default content to write to .py files when the 'template' parameter is omitted.

```default
__version__ = "{version}"
```

--------------------------------

### Configure Artifacts for Version Files in Hatch

Source: https://github.com/jwodder/versioningit/blob/master/docs/hatch.md

If the version file created by the 'write' step is ignored by git/hg, configure Hatch to include it in sdists and wheels.

```toml
[tool.hatch.build]
# Replace the path below with the path to the file created by the
# `write` step:
artifacts = ["src/mypackage/_version.py"]

```

--------------------------------

### Custom format Method Signature

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Defines the expected signature for a custom format method. It receives a VCS description, base version, next version, and user parameters, returning the final project version string.

```python
def funcname(description: versioningit.VCSDescription, base_version: str, next_version: str, params: dict[str, Any]) -> str:
```

--------------------------------

### Read Version from a Text File

Source: https://github.com/jwodder/versioningit/blob/master/docs/runtime-version.md

Read the project version from a text file at runtime using pathlib. This method assumes the version file is located relative to the current file.

```python
from pathlib import Path
__version__ = Path(__file__).with_name("VERSION").read_text().strip()
```

--------------------------------

### Default Template for .txt and files without extension

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

The default content to write to .txt files or files without an extension when the 'template' parameter is omitted.

```default
{version}
```

--------------------------------

### Specify Custom Python Method with Module Directory

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Configures the 'next-version' step to use a custom Python function located in a subdirectory of the project.

```toml
[tool.versioningit.next-version]
method = { module = "mypackage.module", value = "my_next_version", module-dir = "src" }
```

--------------------------------

### Custom next-version Method Signature

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Defines the expected signature for a custom next-version method. It accepts the current version, branch name, and user parameters, returning the next version string.

```python
def funcname(version: str, branch: str | None, params: dict[str, Any]) -> str:
```

--------------------------------

### Custom Onbuild Method Signature

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Signature for a custom onbuild method. It modifies files for sdist or wheel builds based on template fields and parameters.

```python
def funcname(, file_provider: OnbuildFileProvider, is_source: bool, template_fields: dict[str, Any], params: dict[str, Any]) → None:
    pass
```

--------------------------------

### Custom VCS Method Signature

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Defines the expected signature for a custom VCS method. It accepts the project directory and user-supplied parameters, returning a VCS description.

```python
def funcname(project_dir: str | pathlib.Path, params: dict[str, Any]) -> versioningit.VCSDescription:
```

--------------------------------

### Specify Custom Python Method

Source: https://github.com/jwodder/versioningit/blob/master/docs/configuration.md

Configures the 'next-version' step to use a custom Python function defined in a specific module.

```toml
[tool.versioningit.next-version]
method = { module = "mypackage.module", value = "my_next_version" }
```

--------------------------------

### Custom tag2version Method Signature

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Defines the expected signature for a custom tag2version method. It takes a version control tag and user parameters, returning a version string.

```python
def funcname(tag: str, params: dict[str, Any]) -> str:
```

--------------------------------

### Custom Write Method Signature

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Signature for a custom write method. It takes the project directory, template fields, and parameters to write version information.

```python
def funcname(, project_dir: str | pathlib.Path, template_fields: dict[str, Any], params: dict[str, Any]) → None:
    pass
```

--------------------------------

### Custom VCS Method Signature

Source: https://github.com/jwodder/versioningit/blob/master/docs/writing-methods.md

Signature for a custom VCS method. It receives project details and returns version information.

```python
def funcname(, version: str, description: VCSDescription | None, base_version: str | None, next_version: str | None, params: dict[str, Any]) → dict[str, Any]:
    pass
```

--------------------------------

### Increase Verbosity

Source: https://github.com/jwodder/versioningit/blob/master/docs/command.md

Use the -v or --verbose option to increase the amount of log messages displayed. Specify twice for maximum information. The logging level can also be controlled via the VERSIONINGIT_LOG_LEVEL environment variable.

```bash
versioningit -v
```

```bash
versioningit -vv
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.