plesty.sdk.commands.update

CLI command for updating metadata in an existing Plesty project.

Attributes

`NEXT_VERSION_BLOCK`
`_PACKAGING_COVERED`

Functions

`update_command`(→ None)	Update metadata or tooling in an existing Plesty project.
`_install_versioning`(→ None)	Give an existing project the scaffold's snapshot-naming rule.
`_insert_next_version`(→ str)	Return text with `NEXT_VERSION_BLOCK` after `[tool.hatch.version]`.
`_annotate_packaging`(→ None)	Cover `packaging/` in REUSE.toml unless an annotation already does.
`_update_pyproject_author`(→ None)
`_update_pyproject_name`(→ None)

Module Contents

plesty.sdk.commands.update.NEXT_VERSION_BLOCK = Multiline-String

Show Value

"""# What a build between two tags calls itself: the release its line is working
# towards — the next minor on `exp`/`main`, the next patch on `maintain/0.N`.
# The rule reads the branch, so this block is the same on every line and
# travels through merges unchanged. See `packaging/versioning.py`.
[tool.hatch.version.next-version]
method = { module = "versioning", value = "next_version", module-dir = "packaging" }
"""

plesty.sdk.commands.update._PACKAGING_COVERED

plesty.sdk.commands.update.update_command(context: plesty.sdk.context.ApplicationContext, author: str | None, email: str | None, pypi_name: str | None, standard: str | None, no_ci: bool, install_hook: bool, versioning: bool) → None

Update metadata or tooling in an existing Plesty project.

Operates on the directory set via the global –project-dir option (defaults to the current working directory).

Only explicitly provided options are changed; everything else is left as-is.

Parameters:

context (plesty.sdk.context.ApplicationContext)
author (str | None)
email (str | None)
pypi_name (str | None)
standard (str | None)
no_ci (bool)
install_hook (bool)
versioning (bool)

Return type:

None

plesty.sdk.commands.update._install_versioning(project_dir: pathlib.Path) → None

Give an existing project the scaffold’s snapshot-naming rule.

Three pieces, each left alone when already in place: the rule itself, the pyproject.toml block that points versioningit at it, and a REUSE.toml annotation for packaging/ — versioningit imports the rule at build time, and the .pyc Python writes beside it fails reuse lint even though .gitignore hides it from git.

Parameters:: project_dir (pathlib.Path) – The project to update.
Raises:: click.ClickException – If the project is not versioned by versioningit, so there is nothing for the rule to plug into.
Return type:: None

plesty.sdk.commands.update._insert_next_version(text: str) → str

Return text with NEXT_VERSION_BLOCK after [tool.hatch.version].

The block goes before the next table header, so it lands between the vcs setting and [tool.hatch.version.format] as it does in a scaffolded project.

Parameters:: text (str)
Return type:: str

plesty.sdk.commands.update._annotate_packaging(project_dir: pathlib.Path, pyproject_text: str) → None

Cover packaging/ in REUSE.toml unless an annotation already does.

Parameters:

project_dir (pathlib.Path)
pyproject_text (str)

Return type:

None

plesty.sdk.commands.update._update_pyproject_author(pyproject_path: pathlib.Path, author: str | None, email: str | None) → None

Parameters:

pyproject_path (pathlib.Path)
author (str | None)
email (str | None)

Return type:

None

plesty.sdk.commands.update._update_pyproject_name(pyproject_path: pathlib.Path, name: str) → None

Parameters:

pyproject_path (pathlib.Path)
name (str)

Return type:

None