Pin dependencies more tightly, updating versions

[rolandwalker]

Description

Some dependencies had no versioning; others used >= which is prone to breakage as libraries have breaking changes.

This way means more maintenance but is safer against breakage.

Some projects also check in the lockfile for perfect reproducibility.

Where a >= was used, the version was generally updated to the latest, which is probably what was being used in practice.

The ~= operator allows the patch version to increment.

Checklist

• I added this contribution to the changelog.md file.
• I added my name to the AUTHORS file (or it's already there).
• To lint and format the code, I ran

  uv run ruff check && uv run ruff format && uv run mypy --install-types .

[github-actions]

Findings (ordered by severity)

1. Potential regression: lower minimum version for configobj
pyproject.toml:19 now uses configobj ~= 5.0.0, which allows 5.0.0–5.0.x. Previously it required >=5.0.5. If the project relied on fixes introduced in 5.0.5, this change could reintroduce those bugs. Consider pinning to ~=5.0.5 or >=5.0.5,<5.1.
   File: pyproject.toml:19

2. Missing safety check for pinned versions/extras
   Several new pins are very specific (cryptography ~= 46.0.5, pycryptodomex ~= 3.23.0, pip == 26.*, setuptools == 82.*, pytest ~= 9.0.2). If any of these versions are missing on PyPI or have stricter Python/OS wheel constraints, installs will fail for users. Recommend adding a CI step to resolve/install extras on supported Python (>=3.10), e.g. pip install .[ssh,llm,dev] or uv pip install .[ssh,llm,dev].
   Files: pyproject.toml:11-63

Notes

• If the downgrading of the minimum version for configobj is intentional, it would be good to call that out in the PR description or changelog.

If you want, I can draft a CI snippet for the extras-resolve check.

[github-actions]

Findings

1. Potential install breakage for llm/dev extras due to hard pinning build tooling. Pinning pip == 26.* and setuptools == 82.* can make the extra unresolvable on environments where those versions aren’t available or compatible (or if the user’s installer pins different versions). Consider loosening these to a bounded range or moving them to a separate “tooling” extra so runtime deps don’t force installer upgrades. See pyproject.toml:40 and pyproject.toml:49.
2. Possible platform compatibility risk from cryptography ~= 46.0.5. This version may require newer OpenSSL or specific wheels; if users are on older distros, installs can fail. Worth validating against the supported OS matrix or adding a note/constraint if older platforms are still supported. See pyproject.toml:13.

Missing tests / edge cases

1. No tests needed for pin-only changes, but please confirm CI covers the lowest supported Python (3.10) with mycli[llm] and mycli[ssh] extras to catch version compatibility early.