python-gitea 0.9.0__tar.gz → 0.10.1__tar.gz

{python_gitea-0.9.0 → python_gitea-0.10.1}/.github/workflows/support_floor_update.yml

@@ -22,7 +22,7 @@ jobs:
 
             - name: Apply support policy (spec0, from pyproject tool table)
               id: policy
-              uses: isaac-cf-wong/dependency-support-policy-action@7cce60e19b902747b4267c4f8e53820e3f3656ea # v0.2.4
+              uses: isaac-cf-wong/dependency-support-policy-action@c00466ca1b1d902260e56e087c072cbb41ac038b # v0.2.5
               with:
                   mode: update
 

{python_gitea-0.9.0 → python_gitea-0.10.1}/.gitignore

@@ -133,3 +133,7 @@ dmypy.json
 
 # Node.js
 node_modules/
+
+# mutmut
+/mutants/
+/.mutmut-cache

{python_gitea-0.9.0 → python_gitea-0.10.1}/.pre-commit-config.yaml

@@ -16,7 +16,7 @@ repos:
           - id: check-json
 
     - repo: https://github.com/astral-sh/ruff-pre-commit
-      rev: v0.16.3
+      rev: v0.16.4
       hooks:
           - id: ruff
             args: [--fix, --config=pyproject.toml]

{python_gitea-0.9.0 → python_gitea-0.10.1}/CONTRIBUTING.md

@@ -81,6 +81,80 @@ submitting a pull request—this guide will help you get started.
     pytest
     ```
 
+    Mutation testing runs the suite again for each deliberate alteration of the
+    source, and reports the alterations no test noticed:
+
+    ```shell
+    uv run mutmut run                  # every module
+    uv run mutmut run "gitea.cli.*"    # one subtree, while iterating
+    uv run mutmut results              # what survived
+    ```
+
+    A survivor is a change to the code that every test tolerated. Some cannot be
+    killed - a rewritten `typing.cast`, or anything in a `register_commands()`
+    that runs at import time - so read the diff `uv run mutmut show <mutant>`
+    prints before writing a test for one.
+
+    A filter selects which mutants are _run_, not which are written: every module
+    is mutated either way, so a scoped run still reports mutating the whole tree
+    and its progress counter reads `46/9042`, where the denominator counts every
+    mutant written and the numerator counts the ones the filter selected and
+    checked. Take the result of a scoped run from `uv run mutmut results` rather
+    than from that counter: it lists every mutant that was not killed, labelling
+    each as `survived` or as `not checked`, and naming the module it belongs to,
+    so the survivors of a scope are the `survived` entries whose names begin with
+    it. A filter matching no mutant stops the run with an error instead of
+    quietly widening it, so a scoped run that gets as far as testing is one that
+    scoped.
+
+    That listing names no killed mutant, though, so it cannot say how large the
+    scope was or what share of it died. Both are recorded per module, in the
+    `.meta` file mutmut writes beside each mutated module, whose
+    `exit_code_by_key` maps every mutant to the exit code of the run that checked
+    it - `0` survived, `1` killed, `null` never checked. Counting those gives the
+    verdict of a scope, and shows the modules outside it untouched. Point it at
+    the package directory the scope sits in - every module in the tree has a
+    `.meta`, so pointing it at the whole of `src/gitea` prints a line per module:
+
+    ```shell
+    uv run python - <<'PY'
+    import collections, json, pathlib
+
+    status = {0: "survived", 1: "killed", 3: "killed", 5: "no tests", 33: "no tests", None: "not checked"}
+    for meta in sorted(pathlib.Path("mutants/src/gitea/project").glob("*.py.meta")):
+        codes = json.loads(meta.read_text())["exit_code_by_key"]
+        counts = collections.Counter(status.get(c, f"exit {c}") for c in codes.values())
+        if counts:
+            print(f"{meta.name:24} {dict(counts)}")
+    PY
+    ```
+
+    ```text
+    async_project.py.meta    {'killed': 620, 'survived': 16}
+    base.py.meta             {'not checked': 215}
+    project.py.meta          {'killed': 620, 'survived': 16}
+    ```
+
+    That is the output of a run scoped to the two project resource modules: 636
+    mutants each, 1,240 of the 1,272 killed, and the 215 of a module outside the
+    scope sitting unchecked. Start from `rm -rf mutants` when a run has to stand
+    on its own, since the verdicts of one run are otherwise carried into the
+    next.
+
+    To scope what is _written_ as well, and get a counter whose denominator is
+    the scope, point `source_paths` at the modules and let `also_copy` carry the
+    rest of the package that the tests import. Scoped to the same two modules as
+    above, that run reports mutating two files and counts `1272/1272`:
+
+    ```toml
+    [tool.mutmut]
+    source_paths = [
+      "src/gitea/project/project.py",
+      "src/gitea/project/async_project.py",
+    ]
+    also_copy = ["scripts/", "src/"]
+    ```
+
 8. Open a Pull Request
 
     Clearly describe the motivation and scope of your change. Link it to the relevant issue if applicable.

{python_gitea-0.9.0 → python_gitea-0.10.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: python-gitea
-Version: 0.9.0
+Version: 0.10.1
 Summary: A Python package for interacting with the Gitea API, offering a simple interface to access repositories, users, organizations, issues, and more for automation and data management.
 Project-URL: Documentation, https://isaac-cf-wong.github.io/python-gitea
 Project-URL: Source, https://github.com/isaac-cf-wong/python-gitea

{python_gitea-0.9.0 → python_gitea-0.10.1}/docs/dev/architecture.md

@@ -44,6 +44,7 @@ src/gitea/
 ├── milestone/               # Milestone resource (sync + async)
 ├── notification/            # Notification resource (sync + async)
 ├── project/                 # Project resource (sync + async)
+├── organization/            # Organization resource (sync + async)
 ├── cli/                     # Typer CLI application
 │   ├── main.py              # gitea-cli entry point, command registration
 │   ├── config/              # config commands
@@ -54,9 +55,12 @@ src/gitea/
 │   ├── milestone/           # milestone commands
 │   ├── notification/        # notification commands
 │   ├── project/             # project, column, and project-issue commands
+│   ├── organization/        # org commands
+│   ├── repository/          # repo commands
 │   ├── user/                # user commands
 │   └── utils/               # auth resolution, API helpers, conversions
-└── utils/                   # Logging, pagination, and response helpers
+└── utils/                   # Logging, field names, pagination, and response helpers
+    ├── fields.py            # Field-name convention and compatibility aliases
     ├── log.py               # Logger setup
     ├── pagination.py        # Paginated-listing walkers
     └── response.py          # Response processing helpers
@@ -85,6 +89,7 @@ with Gitea(token="...", base_url="...") as client:
     client.milestone      # Milestone
     client.notification   # Notification
     client.project        # Project
+    client.organization   # Organization
 ```
 
 ## Resource Layer

{python_gitea-0.9.0 → python_gitea-0.10.1}/docs/user-guide/cli.md

@@ -65,7 +65,7 @@ command:
 
 - API commands report `status_code`.
 - Commands that page through the API add counts, such as `column_count` and
-  `issue_count` for `project issues`.
+  `issue_count` for `project issues` and `project show`.
 - `config` commands report `config_path`.
 - It is `{}` when the command made no call at all.
 
@@ -81,10 +81,45 @@ failing over an enrichment of it.
 
 Tokens are never included in the output of `config` commands in either format.
 
+## Field names
+
+Every field of `data` is named as the Gitea API names it. Nothing is renamed and
+nothing is dropped on the way out, so a key can be looked up in
+[Gitea's own API reference](https://docs.gitea.com/api/1.24/) rather than in
+this CLI's source, and the same value never arrives under two names depending on
+which command fetched it.
+
+A field the API cannot send is added only where it carries something the API has
+no way of saying, and is documented with the command that adds it: `column_id`
+on the project entries of `issue get`, and `issue_count` and `issue_ids` on the
+columns of `project show`, are the ones today. Such a field is never a second
+name for a field already in the payload.
+
+Two consequences worth knowing:
+
+- A project column is `title`, not `name`:
+
+    ```console
+    $ gitea-cli --output json project column list --owner my-org --project-id 31
+    {
+      "data": [{ "id": 117, "title": "Working", "default": false, "sorting": 0, ... }],
+      "metadata": { "status_code": 200 }
+    }
+    ```
+
+- A field whose name misleads is documented rather than renamed. `comments` on
+  an issue is the _number_ of comments; `gitea-cli issue comment list` reads the
+  bodies.
+
+The Python client follows the same convention and additionally keeps a field
+name callers already wrote readable as an alias - `column["name"]` reads the
+title - which the [Python API guide](python-api.md#field-names) describes. An
+alias is never emitted, so it cannot appear in the JSON above.
+
 ## Option naming
 
-Every resource command addresses its target the same way, so an invocation can
-be written without reading `--help` first:
+Every command that addresses something an account owns names its target the same
+way, so an invocation can be written without reading `--help` first:
 
 | Option          | Meaning                                                  |
 | --------------- | -------------------------------------------------------- |
@@ -123,6 +158,16 @@ are required together because there is no scope for them to fall back to:
 neither `--owner` nor `--repository` it acts on the authenticated user's
 notifications, and the two must be passed together or not at all.
 
+A command whose target is an account rather than something an account owns takes
+no `--owner` at all, and names the account with `--username` instead: `org list`
+lists an account's organizations and `user get` reads an account's profile, both
+answering for the account the token belongs to when `--username` is omitted.
+
+`repo list` is the one command where the _kind_ of owner matters: Gitea serves
+an organization's repositories and a user's at different endpoints, so
+`--owner-type` says which of the two `--owner` names. It defaults to
+`organization`.
+
 ### Deprecated option names
 
 `--index` has been renamed to `--issue-id`, so that one option name means "which
@@ -169,9 +214,11 @@ endpoint to serve it with, so they answer by naming the option to pass.
     - Optional: `--state`, `--labels`, `--search-string`, `--created-by`,
       `--assigned-by`, `--since`, `--before`, `--page`, `--limit`
 - `gitea-cli issue get --owner <owner> --repository <repo> --issue-id <number>`
-    - The `comment_count` field is the number of comments on the issue, not the
+    - The `comments` field is the number of comments on the issue, not the
       comments themselves; use `gitea-cli issue comment list` to read the
-      bodies.
+      bodies. The field keeps the API's name, as
+      [the field-name convention](#field-names) requires: this command used to
+      rename it to `comment_count` and was alone in doing so.
     - Each entry of `projects` carries a `column_id`: the column the issue's
       card sits in, or `null` when the issue has no card on that project. Gitea
       does not report it on the issue itself, so it is resolved from each
@@ -187,6 +234,13 @@ endpoint to serve it with, so they answer by naming the option to pass.
 - `gitea-cli issue edit --owner <owner> --repository <repo> --issue-id <number>`
     - Optional: `--title`, `--body`, `--state`, `--assignees`, `--milestone`,
       `--due-date`
+- `gitea-cli issue close --owner <owner> --repository <repo> --issue-id <number>`
+    - Optional: `--comment`
+    - Closes the issue, which `issue edit --state closed` also does; this is the
+      shorter way to say it and the one that takes a `--comment`.
+    - `--comment` posts that body on the issue after it is closed. The issue is
+      closed first, so a comment that is refused leaves the issue closed rather
+      than the close undone; the result is the closed issue either way.
 - `gitea-cli issue dependency add --owner <owner> --repository <repo> --issue-id <number>`
     - Required: `--dependency-owner <owner>`, `--dependency-repository <repo>`,
       `--dependency-issue-id <number>`
@@ -252,6 +306,8 @@ gitea-cli project list --owner my-org --repository my-repo  # that repository's
     - Optional: `--description`, `--card-type`, `--template-type`
 - `gitea-cli project list --owner <owner> [--repository <repo>]`
 - `gitea-cli project get --owner <owner> [--repository <repo>] --project-id <id>`
+- `gitea-cli project show --owner <owner> [--repository <repo>] --project-id <id>`
+    - Optional: `--full`
 - `gitea-cli project edit --owner <owner> [--repository <repo>] --project-id <id>`
     - Optional: `--title`, `--description`, `--state`, `--card-type`
 - `gitea-cli project delete --owner <owner> [--repository <repo>] --project-id <id>`
@@ -264,7 +320,11 @@ gitea-cli project list --owner my-org --repository my-repo  # that repository's
 - `gitea-cli project issue add --owner <owner> [--repository <repo>] --project-id <id> --column-id <id> --issue-id <id>`
     - Optional: `--issue-repository`
 - `gitea-cli project issue move --owner <owner> [--repository <repo>] --project-id <id> --column-id <id> --issue-id <id>`
-    - Optional: `--sorting`, `--issue-repository`
+    - Optional: `--sorting`, `--issue-repository`, `--add-if-missing`
+    - Moves the card the issue already has on the project, and confirms it
+      arrived in `--column-id`. An issue with no card there is reported as an
+      error naming `project issue add`; `--add-if-missing` has this command put
+      it in `--column-id` instead.
 - `gitea-cli project issue remove --owner <owner> [--repository <repo>] --project-id <id> --column-id <id> --issue-id <id>`
     - Optional: `--issue-repository`
 
@@ -282,6 +342,40 @@ for you:
   ID. `--issue-repository` also overrides `--repository`, for the case of a
   repository project holding an issue from elsewhere.
 
+`add` and `move` are not two ways of doing the same thing. `add` puts an issue
+on a board, giving it a card in a column; `move` relocates the card it already
+has there, and an issue with no card has nothing to relocate. Gitea's move
+endpoint does not say so - it moves the row relating the issue to the project,
+of which there is none, and answers with a success and an empty body having
+moved nothing - so the command finds the card first and reports its absence
+itself:
+
+```console
+$ gitea-cli project issue move --owner my-org --project-id 1 --column-id 2 \
+      --issue-repository my-repo --issue-id 42
+No column of project 1 holds issue #42 of my-org/my-repo (global ID 1854), so there is
+no card to move. [...] Put the issue on the board with 'gitea-cli project issue add
+--owner my-org --project-id 1 --column-id 2 --issue-id 42 --issue-repository my-repo',
+or pass --add-if-missing to have this command do that when there is no card yet.
+```
+
+`--add-if-missing` makes the one call do either, which is what a script
+advancing cards through columns wants: the card is moved when it exists and
+created in `--column-id` when it does not. `--sorting` is refused on that second
+path rather than dropped, since the endpoint putting a card on a board takes no
+position within the column. A board that cannot be read is reported as such and
+stops the move: a failed lookup is not evidence that the issue has no card.
+
+Whichever call is made, `--column-id` is then read back, because the success the
+endpoint answers with has already been shown not to mean the card went anywhere.
+A zero exit status therefore says the card was seen in that column, rather than
+that Gitea accepted a request to put it there - and the three ways that can fail
+are reported apart: the issue has no card at all, the card is not in the column
+it was sent to, or the reading back could not be done and it is unknown which.
+It does not say the card is still there: the calls are separate requests, and
+Gitea has no conditional move to make them one, so a card taken off the board
+after the command read it is outside what any client can report on.
+
 The global ID the command used comes back as `metadata.resolved_issue_id`. A
 number the repository does not have, and a call the project endpoint refuses,
 are both reported as errors naming the issue and what to check - never as an
@@ -298,6 +392,31 @@ instance is down.
     - Optional: `--full-name`, `--website`, `--location`, `--language`,
       `--theme`, `--diff-view-style`, `--hide-email`, `--hide-activity`
 
+### Org - discover organizations
+
+- `gitea-cli org list`
+    - Optional: `--username`, `--page`, `--limit`
+    - Lists the organizations of the account the token belongs to; `--username`
+      lists those of another account instead.
+    - Gitea also has a site-wide listing of every organization, which a token
+      that is not scoped for it is refused. This command does not read from it,
+      so it answers with the organizations of an account and never with the
+      instance's.
+
+### Repo - discover repositories
+
+- `gitea-cli repo list --owner <owner>`
+    - Optional: `--owner-type`, `--page`, `--limit`
+    - `--owner-type` is `organization` (the default) or `user`: Gitea serves the
+      two at different endpoints - `/orgs/<owner>/repos` and
+      `/users/<owner>/repos` - and an owner's name does not say which of the two
+      it is.
+
+```bash
+gitea-cli repo list --owner my-org                     # an organization's repositories
+gitea-cli repo list --owner alice --owner-type user    # a user's repositories
+```
+
 ### Watch - report what changed since the last run
 
 Every other command answers a question about the instance now. `watch` answers
@@ -446,8 +565,8 @@ gitea-cli issue create \
     --milestone 3
 ```
 
-Move an issue into a project column, addressing it by the number shown in the
-web UI:
+Put an issue on a project board, in a column of it, addressing the issue by the
+number shown in the web UI:
 
 ```bash
 gitea-cli project issue add \
@@ -458,8 +577,9 @@ gitea-cli project issue add \
     --issue-id 42
 ```
 
-Move `my-repo#42` on an organization project, where the repository holding the
-issue has to be named separately:
+Move the card of `my-repo#42` on an organization project, where the repository
+holding the issue has to be named separately, and put it on the board if it is
+not there yet:
 
 ```bash
 gitea-cli project issue move \
@@ -467,7 +587,8 @@ gitea-cli project issue move \
     --project-id 1 \
     --column-id 2 \
     --issue-repository my-repo \
-    --issue-id 42
+    --issue-id 42 \
+    --add-if-missing
 ```
 
 List the issues sitting in one column of an organization project (omit
@@ -486,6 +607,30 @@ Show every card on a project together with the column it is in:
 gitea-cli project issues --owner my-org --project-id 1
 ```
 
+Read a board's shape in one call - the project, its columns, and how many cards
+sit in each of them. `project get` answers with the project alone, which says
+nothing about where the cards are:
+
+```console
+$ gitea-cli --output json project show --owner my-org --project-id 31
+{
+  "data": {
+    "project": { "id": 31, "title": "Board", "state": "open", ... },
+    "columns": [
+      { "id": 117, "title": "Working", ..., "issue_count": 2, "issue_ids": [1873, 1874] }
+    ]
+  },
+  "metadata": { "status_code": 200, "column_count": 1, "issue_count": 2 }
+}
+```
+
+Each column is the columns endpoint's own object with `issue_count` and
+`issue_ids` added to it, and `issue_ids` holds the global issue IDs the project
+endpoints take - `--issue-id` without `--issue-repository`. Add `--full` to have
+each column carry its issues themselves, under `issues`, rather than their IDs
+alone. Every page of columns, and of each column's issues, is walked, so the
+counts describe the whole board.
+
 Report what changed across two repositories and a board since the last run,
 quietly enough to be worth a `cron` entry:
 

{python_gitea-0.9.0 → python_gitea-0.10.1}/docs/user-guide/python-api.md

@@ -90,6 +90,38 @@ Both are best-effort, and `column_id` should be read with that in mind:
 - The columns of a user-owned (individual) project live under endpoints this
   library does not wrap, so such a project's `column_id` is always `None`.
 
+That last point is about the enrichment and not about the walk itself.
+`find_card_column_id` is the walk on its own — one project, one issue, the
+column holding its card or `None` when no column of the board lists it — and it
+raises what the lookup raised rather than logging it, for a caller that has to
+tell "no card" apart from "could not be read":
+
+```python
+from gitea.client.gitea import Gitea
+from gitea.issue import find_card_column_id
+
+with Gitea(token="TOKEN", base_url="https://gitea.example.com") as client:
+    column_id = find_card_column_id(
+        client=client,
+        owner="my-org",
+        repository=None,  # the organization's own project; a repository's names it
+        project_id=1,
+        issue_id=1854,  # the global ID, which is what the columns list their issues by
+    )
+    print("not on the board" if column_id is None else column_id)
+```
+
+`find_async_card_column_id` is its `await`-based twin. Asking this before moving
+a card is what `gitea-cli project issue move` does: Gitea's move endpoint moves
+the row relating an issue to a project, and for an issue that is not on the
+project there is none to move, so the call comes back a success having done
+nothing.
+
+`column_holds_card` is the same question about a single named column, at the
+cost of that column's listing rather than the board's — which is what the walk
+above asks per column, and what the same command asks again after the move to
+confirm the card arrived. `async_column_holds_card` is its `await`-based twin.
+
 ## Asynchronous Client
 
 The `AsyncGitea` client has the same structure but `await`-based, and it uses
@@ -126,12 +158,49 @@ is simpler and sufficient.
 | `client.milestone`    | Milestones                            |
 | `client.notification` | Notifications                         |
 | `client.project`      | Projects, columns, and project issues |
+| `client.organization` | Organizations                         |
 
 Each resource is implemented in a synchronous class (e.g. `gitea.issue.Issue`)
 and an async class (e.g. `gitea.issue.AsyncIssue`); some modules re-export them
 from the package `__init__` (e.g. `from gitea.issue import Issue`). See the
 [API Reference](../reference/index.md) for the full method list and signatures.
 
+## Field Names
+
+A payload returned by a client method is the JSON the Gitea API sent, keyed as
+the API keys it. Nothing is renamed and nothing is dropped, in the client
+dictionaries and in [the CLI's JSON envelope](cli.md#field-names) alike, so a
+key is looked up in Gitea's API reference and not in this library's source.
+
+A project column is therefore `title`:
+
+```python
+columns, _ = client.project.list_project_columns(owner="my-org", repository=None, project_id=31)
+print(columns[0]["title"])  # 'Working'
+```
+
+`name` reads it too. It is an alias, not a second key: reading a payload by it
+works, and enumerating or serializing the payload sees `title` alone, so nothing
+downstream can come to depend on a name the API does not use.
+
+```python
+column = columns[0]
+column["name"]        # 'Working' - reads the title
+column.get("name")    # 'Working'
+"name" in column      # True
+list(column)          # ['id', 'title', 'default', 'sorting', ...] - no 'name'
+json.dumps(column)    # {"id": 117, "title": "Working", ...} - no 'name'
+```
+
+Only reading is widened. `column["name"] = x` writes a field called `name`, as
+it would on any dictionary, rather than changing the title through a name Gitea
+does not use.
+
+`gitea.utils.fields` holds the convention itself, the record types declaring the
+aliases of a resource, and the bar an alias has to clear to be added: a name
+callers have written, not a name that reads well. Today there is one, `name` on
+a project column.
+
 ## Detecting What Changed
 
 `gitea.watch` is not a resource: it holds the change detection that

{python_gitea-0.9.0 → python_gitea-0.10.1}/mkdocs.yml

@@ -132,6 +132,11 @@ nav:
                       - Overview: reference/gitea/project/index.md
                       - Project: reference/gitea/project/project.md
                       - Async Project: reference/gitea/project/async_project.md
+                - Organization:
+                      - Overview: reference/gitea/organization/index.md
+                      - Organization: reference/gitea/organization/organization.md
+                      - Async Organization:
+                            reference/gitea/organization/async_organization.md
                 - User:
                       - Overview: reference/gitea/user/index.md
                       - User: reference/gitea/user/user.md

{python_gitea-0.9.0 → python_gitea-0.10.1}/pyproject.toml

@@ -30,7 +30,12 @@ dependencies = [
 [dependency-groups]
 dev = [
   "ruff>=0.16.3",
-  "prek>=0.4.13",
+  # The mutation runner, in the environment `uv run` resolves, so that
+  # `uv run mutmut run` reaches the same interpreter as `uv run pytest` and finds
+  # the pytest plugins the suite's own options need. Run from a tool environment
+  # of its own it cannot read `--cov`, and the run dies at collection.
+  "mutmut>=3.7.0",
+  "prek>=0.4.14",
   "pytest-github-actions-annotate-failures>=0.4.2",
   "pytest-cov>=7.1.0",
   "pytest-mock>=3.15.1",
@@ -75,6 +80,34 @@ source = "vcs"
 [tool.hatch.build.targets.wheel]
 packages = ["src/gitea"]
 
+[tool.mutmut]
+# The suite imports from `scripts/` (see `pythonpath` under
+# `[tool.pytest.ini_options]`), so the copy of the tree that mutmut runs it from
+# needs that directory as well - without it every mutant is reported as killed by
+# a collection error in `tests/test_release_version.py`.
+source_paths = ["src/gitea/"]
+also_copy = ["scripts/"]
+# mutmut runs the suite against a rewritten copy of each module, in which every
+# mutated function is replaced by a table of its variants. A test reading a module
+# rather than calling it therefore reads the instrumentation rather than the code,
+# and fails for every mutant - a red baseline, which reports every mutant as
+# killed. Two do: one asserts on the *text* of a module, the other enumerates the
+# methods of a class, which the variants are bound to as members of. Both are
+# deselected here, and are run by `pytest` as usual.
+pytest_add_cli_args = [
+  "--deselect",
+  "tests/utils/test_utils_pagination.py::TestEndOfListing::test_the_walkers_decide_nothing_of_their_own",
+  "--deselect",
+  "tests/project/test_project_requests.py::test_every_project_method_is_declared",
+]
+# A mutant is judged to hang when its tests exceed `timeout_multiplier` times what
+# they took clean, plus this constant. Most tests here take a millisecond or two,
+# so the default constant of one second leaves a budget an unmutated run can miss
+# on a loaded machine - and a mutant reported as a timeout has no verdict at all:
+# it is not known to be caught, and it is not reported as surviving either. Ten
+# seconds is still far below anything a real hang would finish in.
+timeout_constant = 10.0
+
 [tool.coverage.run]
 branch = true
 

python_gitea-0.10.1/src/gitea/cli/issue/close.py

@@ -0,0 +1,106 @@
+"""Close issues command."""
+
+from __future__ import annotations
+
+from typing import Annotated
+
+import typer
+
+from gitea.cli.utils.options import DEPRECATED_INDEX_HELP, ISSUE_ID_HELP, REPOSITORY_REQUIRED_HELP
+
+
+def close_command(
+    ctx: typer.Context,
+    owner: Annotated[str, typer.Option("--owner", help="Owner of the repository.")],
+    repository: Annotated[str | None, typer.Option("--repository", help=REPOSITORY_REQUIRED_HELP)] = None,
+    issue_id: Annotated[int | None, typer.Option("--issue-id", help=ISSUE_ID_HELP)] = None,
+    index: Annotated[int | None, typer.Option("--index", help=DEPRECATED_INDEX_HELP, hidden=True)] = None,
+    comment: Annotated[
+        str | None,
+        typer.Option("--comment", help="Body of a comment to post on the issue as it is closed."),
+    ] = None,
+    account_name: Annotated[
+        str | None,
+        typer.Option(
+            "--account-name",
+            help="Name of the account to use for authentication.",
+        ),
+    ] = None,
+    token: Annotated[
+        str | None,
+        typer.Option(
+            "--token",
+            help="Token for authentication. If not provided, the token from the specified account will be used.",
+        ),
+    ] = None,
+    base_url: Annotated[
+        str | None,
+        typer.Option(
+            "--base-url",
+            help="Base URL of the Gitea platform. If not provided, the base URL from the specified account will be used.",
+        ),
+    ] = None,
+) -> None:
+    """Close an issue in a repository.
+
+    Args:
+        ctx: The Typer context.
+        owner: The owner of the repository.
+        repository: The name of the repository, which this command requires.
+        issue_id: The issue number shown in the web UI.
+        index: The deprecated name of `issue_id`.
+        comment: The body of a comment to post on the issue as it is closed. No
+            comment is posted when it is omitted.
+        account_name: Name of the account to use for authentication.
+        token: Token for authentication. If not provided, the token from the specified account will be used.
+        base_url: Base URL of the Gitea platform. If not provided, the base URL from the specified account will be used.
+
+    """
+    from typing import Any  # noqa: PLC0415
+
+    from gitea.cli.utils.api import execute_api_command  # noqa: PLC0415
+    from gitea.cli.utils.auth import get_auth_params  # noqa: PLC0415
+    from gitea.cli.utils.options import require_repository, resolve_issue_id  # noqa: PLC0415
+    from gitea.client.gitea import Gitea  # noqa: PLC0415
+
+    token, base_url = get_auth_params(
+        config_path=ctx.obj.get("config_path"),
+        account_name=account_name,
+        token=token,
+        base_url=base_url,
+    )
+
+    def api_call() -> tuple[dict[str, Any] | list[dict[str, Any]], dict[str, Any]]:
+        """Close the issue, and comment on it when a comment was given.
+
+        The issue is closed before the comment is posted, so a comment that
+        cannot be posted leaves the issue closed rather than leaving the close
+        undone. The result is the closed issue: the comment is what the command
+        does on the way past, not what it was asked for.
+
+        Returns:
+            A tuple containing the issue data and metadata.
+
+        """
+        target_repository = require_repository(repository, command="gitea-cli issue close")
+        target_issue = resolve_issue_id(issue_id=issue_id, index=index, command="gitea-cli issue close")
+
+        with Gitea(token=token, base_url=base_url) as client:
+            closed = client.issue.edit_issue(
+                owner=owner,
+                repository=target_repository,
+                index=target_issue,
+                state="closed",
+            )
+
+            if comment is not None:
+                client.comment.create_comment(
+                    owner=owner,
+                    repository=target_repository,
+                    index=target_issue,
+                    body=comment,
+                )
+
+            return closed
+
+    execute_api_command(api_call=api_call, base_url=base_url, command_name="gitea-cli issue close")