Remove python 3.9

[vyagubov]

Python 3.9 reached end-of-life in October 2025, so I decided to remove it.

Summary by CodeRabbit

• Chores
  • Minimum Python requirement raised to 3.10 (now 3.10–3.13).
  • CI/CD workflows updated to use Python 3.10 and the newer setup action (v5).
  • Added package classifiers to improve packaging and discoverability.
  • Minor tooling/comment adjustment in the CLI with no runtime impact.
  • No public API or behavior changes.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[github-actions]

👋 @vyagubov
Thank you for raising your pull request.
Please make sure to add tests and document all user-facing changes.
You can do this by editing the docs files in this pull request.

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

Updated CI workflows and project metadata to require Python 3.10, added poetry classifiers in pyproject.toml, and added a type-ignore pragma to the ElementaryCLI class in elementary/cli/cli.py.

Changes

Cohort / File(s)	Summary
GitHub Actions Workflows .github/workflows/release.yml, .github/workflows/run-precommit.yml, .github/workflows/test-github-action.yml, .github/workflows/test-warehouse.yml	Bumped actions/setup-python from v4 to v5 and updated Python version from 3.9 to 3.10. No other steps or control flow changes.
Project Configuration pyproject.toml	Raised Python dependency constraint from >=3.9,<3.14 to >=3.10,<3.14 and added [tool.poetry] classifiers (language, audience, license, supported Python 3.10–3.13, topic).
CLI Type-check pragma elementary/cli/cli.py	Added # type: ignore[misc, valid-type] pragma to the ElementaryCLI class declaration; no runtime/API changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A hop to Python three point ten,
Workflows nudged and classifiers penned,
A tiny pragma, quiet and neat,
CI purrs on steady feet,
I nibble code and hop again. 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Remove python 3.9' directly and clearly summarizes the main change: dropping Python 3.9 support across workflows and dependencies.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[vyagubov]

@NoyaOffer @arbiv FYI. Maybe it makes sense to merge current PR before the next release.

[vyagubov]

@haritamar
click.MultiCommand is not recognized as a valid base class by mypy
due to click typing limitations. My last commit adds a targeted type ignore
to avoid false-positive errors on Python 3.10+.

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@elementary/cli/cli.py`:
- Line 39: The type-ignore comment on the ElementaryCLI class is misleading;
update it to accurately state why the ignore is used or eliminate it by aligning
method signatures: either change the comment to "# type: ignore[misc,
valid-type]  # Method signatures differ from click.MultiCommand stubs" or modify
ElementaryCLI.list_commands to return a Sequence[str] (e.g., return
list(self._commands.keys())) and annotate ElementaryCLI.get_command to return
Command | None to match Click's stubs; ensure both method signatures and return
types conform to click.MultiCommand expectations so the scoped type ignore is no
longer necessary.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

click types-click MultiCommand mypy typing issue 2025

💡 Result:

The most common cause is having types-click installed while using click>=8.0.

• click ships its own type hints/stubs since v8.0, so types-click is no longer needed and can conflict with Click’s bundled annotations (often showing up around classes like click.MultiCommand). [1]
• Fix: uninstall types-click (and then re-run mypy), keeping only click installed. If you must use types-click, you generally need to pin click<8. [1]

If the problem is an actual stub bug, the types-click stubs come from typeshed, and fixes should be filed/contributed there. [1][2]

Sources:
[1] https://pypi.org/project/types-click/
[2] https://github.com/python/typeshed

---

🌐 Web query:

click library Python type hints MultiCommand subclassing support

💡 Result:

Yes—Click supports subclassing click.MultiCommand (and click.Group) and it has type-hint support:

• Subclassing support: A custom multi-command is implemented by overriding list_commands(ctx) and get_command(ctx, cmd_name). Click’s docs explicitly describe this extension point for Group / MultiCommand. [2]
• Type hints: Click ships with type annotations / stubs since Click 8.0 (so you typically don’t need types-click on modern Click). [1]
• Typed MultiCommand API: In the Click API docs, get_command is documented as returning Command | None and list_commands as List[str], which is what type checkers will expect your overrides to match. [3]

Sources:
[1] https://pypi.org/project/types-click/
[2] https://pocoo-click.readthedocs.io/en/latest/advanced/
[3] https://dokk.org/documentation/pallets-click/8.1.7/api/

---

🏁 Script executed:

# Find dependency files
fd -e "pyproject.toml" -e "setup.py" -e "requirements.txt" -e "setup.cfg" | head -20

Repository: elementary-data/elementary

Length of output: 52

---

🏁 Script executed:

# Check for mypy configuration
fd -e "mypy.ini" -e ".mypy.ini" | head -10
cat pyproject.toml 2>/dev/null | grep -A 20 "\[tool.mypy\]" || true

Repository: elementary-data/elementary

Length of output: 52

---

🏁 Script executed:

# Search for click and types-click in dependencies
grep -r "types-click\|click" pyproject.toml setup.py setup.cfg requirements.txt 2>/dev/null || true

Repository: elementary-data/elementary

Length of output: 402

---

🏁 Script executed:

# Check full pyproject.toml for types-click and mypy config
cat pyproject.toml | head -150

Repository: elementary-data/elementary

Length of output: 2653

---

🏁 Script executed:

# Check if types-click appears anywhere in dependencies
grep -i "types.click" pyproject.toml || echo "types-click not found in pyproject.toml"

Repository: elementary-data/elementary

Length of output: 109

---

🏁 Script executed:

# Check if there's a lock file indicating actual versions
ls -la | grep -E "\.lock|poetry\.lock|Pipfile"

Repository: elementary-data/elementary

Length of output: 52

---

🏁 Script executed:

# Check for mypy configuration in pyproject.toml
cat pyproject.toml | grep -A 30 "\[tool.mypy\]"

Repository: elementary-data/elementary

Length of output: 52

---

🏁 Script executed:

# Check if there's a mypy.ini or .mypy.ini file
find . -maxdepth 2 -name "mypy.ini" -o -name ".mypy.ini" -o -name "mypy.cfg" 2>/dev/null | head -5

Repository: elementary-data/elementary

Length of output: 80

---

🏁 Script executed:

# Verify the actual click version being used and Python version support
cat pyproject.toml | grep -E "python|click" | head -10

Repository: elementary-data/elementary

Length of output: 366

---

🏁 Script executed:

# Check mypy.ini configuration
cat ./mypy.ini

Repository: elementary-data/elementary

Length of output: 358

---

🏁 Script executed:

# Check the actual ElementaryCLI class to understand context
cat -n elementary/cli/cli.py | head -60

Repository: elementary-data/elementary

Length of output: 2271

---

Scoped type ignore is good practice, but reconsider the explanatory comment.

Using specific error codes (misc, valid-type) rather than a blanket ignore is correct. However, the suggested comment is inaccurate—Click 8.0+ has full type stub support for MultiCommand subclassing. The actual issue is likely method return type mismatches: list_commands() returns dict_keys but the type stub expects Sequence[str], and get_command() may have signature mismatches.

If the type ignore is still necessary, a more accurate comment would be: # type: ignore[misc, valid-type] # Method signatures differ from click.MultiCommand stubs. Alternatively, consider adjusting method signatures to match Click's type expectations (return list() from list_commands(), explicitly type get_command() return as Command | None).

🤖 Prompt for AI Agents

In `@elementary/cli/cli.py` at line 39, The type-ignore comment on the
ElementaryCLI class is misleading; update it to accurately state why the ignore
is used or eliminate it by aligning method signatures: either change the comment
to "# type: ignore[misc, valid-type]  # Method signatures differ from
click.MultiCommand stubs" or modify ElementaryCLI.list_commands to return a
Sequence[str] (e.g., return list(self._commands.keys())) and annotate
ElementaryCLI.get_command to return Command | None to match Click's stubs;
ensure both method signatures and return types conform to click.MultiCommand
expectations so the scoped type ignore is no longer necessary.