plesty.sdk.commands.update
==========================

.. py:module:: plesty.sdk.commands.update

.. autoapi-nested-parse::

   CLI command for updating metadata in an existing Plesty project.



Attributes
----------

.. autoapisummary::

   plesty.sdk.commands.update.NEXT_VERSION_BLOCK
   plesty.sdk.commands.update._PACKAGING_COVERED


Functions
---------

.. autoapisummary::

   plesty.sdk.commands.update.update_command
   plesty.sdk.commands.update._install_versioning
   plesty.sdk.commands.update._insert_next_version
   plesty.sdk.commands.update._annotate_packaging
   plesty.sdk.commands.update._update_pyproject_author
   plesty.sdk.commands.update._update_pyproject_name


Module Contents
---------------

.. py:data:: NEXT_VERSION_BLOCK
   :value: Multiline-String

   .. raw:: html

      <details><summary>Show Value</summary>

   .. code-block:: python

      """# 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" }
      """

   .. raw:: html

      </details>



.. py:data:: _PACKAGING_COVERED

.. py:function:: 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.


.. py:function:: _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.

   :param project_dir: 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.


.. py:function:: _insert_next_version(text: str) -> str

   Return *text* with :data:`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.


.. py:function:: _annotate_packaging(project_dir: pathlib.Path, pyproject_text: str) -> None

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


.. py:function:: _update_pyproject_author(pyproject_path: pathlib.Path, author: str | None, email: str | None) -> None

.. py:function:: _update_pyproject_name(pyproject_path: pathlib.Path, name: str) -> None