deps: update tiktoken and pydantic-core for python3.14 compatibility

[donbowman]

No description provided.

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Update tiktoken and pydantic for Python 3.14 support

✨ Enhancement

Walkthroughs

Description

• Update tiktoken from 0.8.0 to 0.12.0
• Update pydantic from 2.8.2 to 2.13.3
• Improve Python 3.14 compatibility

Diagram

flowchart LR
  A["requirements.txt"] -- "tiktoken 0.8.0 → 0.12.0" --> B["Updated Dependencies"]
  A -- "pydantic 2.8.2 → 2.13.3" --> B
  B -- "Python 3.14 Compatibility" --> C["Enhanced Support"]

Loading

File Changes

1. requirements.txt Dependencies +2/-2

Dependency version updates for Python 3.14

• Updated tiktoken from version 0.8.0 to 0.12.0
• Updated pydantic from version 2.8.2 to 2.13.3
• Changes support improved Python 3.14 compatibility

requirements.txt

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0)

1. Brittle files.get calls 🐞 Bug ☼ Reliability ⭐ New

Description

GitLabProvider calls python-gitlab's Project.files.get using positional arguments, while other repo
call sites use explicit keyword arguments (file_path/ref). With the major python-gitlab upgrade,
these positional calls are brittle and can raise TypeError or bind the wrong parameters, breaking
GitLab file read/write paths (e.g., get_pr_file_content).

Code

requirements.txt[25]

+python-gitlab==8.3.0

Evidence

The PR upgrades python-gitlab to a new major version. In the GitLab provider, the same API is
invoked both with keyword arguments (file_path/ref) and with positional arguments; this
inconsistency indicates the provider relies on parameter ordering for correctness in some places
while being explicit in others, increasing break risk across major upgrades.

requirements.txt[22-35]
pr_agent/git_providers/gitlab_provider.py[350-374]
pr_agent/git_providers/gitlab_provider.py[93-99]
tests/e2e_tests/test_gitlab_webhook.py[40-42]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`GitLabProvider.get_pr_file_content()` and `GitLabProvider.create_or_update_pr_file()` call `project.files.get(file_path, branch)` positionally. Elsewhere in the repo, the same API is called with explicit keyword arguments (`file_path=...`, `ref=...`). With the major `python-gitlab` upgrade, these positional calls are brittle.

### Issue Context
This PR bumps `python-gitlab` from 3.15.0 to 8.3.0.

### Fix Focus Areas
- requirements.txt[25-25]
- pr_agent/git_providers/gitlab_provider.py[350-374]
- pr_agent/git_providers/gitlab_provider.py[93-99]
- tests/e2e_tests/test_gitlab_webhook.py[40-42]

### Suggested change
- Replace positional calls with explicit keywords, e.g.:
 - `project.files.get(file_path=file_path, ref=branch)`
- Update any related unit tests that assert positional calls (e.g., `assert_called_once_with(...)`) to match keyword usage.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. No Python 3.14 CI 🐞 Bug ☼ Reliability

Description

The PR’s stated goal is Python 3.14 compatibility, but the repo’s automation (publish workflows and
Docker builds) is pinned to Python 3.12 and there is no CI job that installs/runs on Python 3.14, so
3.14-specific dependency/install regressions will not be caught automatically.

Code

requirements.txt[R28-34]

+tiktoken==0.12.0
ujson==5.8.0
uvicorn==0.22.0
tenacity==8.2.3
gunicorn==23.0.0
pytest-cov==7.0.0
-pydantic==2.8.2
+pydantic==2.13.3

Evidence

The PR changes runtime dependency pins in requirements.txt, but the existing automation paths that
build/install the package are configured to use Python 3.12 only, so they do not validate the PR’s
Python 3.14 compatibility goal.

requirements.txt[28-34]
.github/workflows/publish.yml[70-74]
.github/workflows/publish.yml[147-150]
docker/Dockerfile[1-10]
docker/Dockerfile.lambda[1-9]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
This PR updates dependency pins (tiktoken, pydantic) to achieve Python 3.14 compatibility, but current automation paths only run on Python 3.12, so Python 3.14 install/runtime issues won’t be detected automatically.
### Issue Context
The publish workflow and Docker images are pinned to Python 3.12. There is no workflow that installs the package (or at least resolves/install dependencies) on Python 3.14.
### Fix Focus Areas
- .github/workflows/publish.yml[70-74]
- .github/workflows/publish.yml[147-150]
- docker/Dockerfile[1-10]
- docker/Dockerfile.lambda[1-9]
### What to change
- Add a CI job (either in an existing workflow or a new one) that runs on Python 3.14 and at minimum performs:
- `pip install -r requirements.txt`
- `pip install .`
- (optionally) a minimal import smoke test (e.g., `python -c "import pr_agent"`)
- Keep existing Python 3.12 jobs; this is additive validation for the PR’s stated compatibility target.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Mixed GitLab error imports 🐞 Bug ⚙ Maintainability ⭐ New

Description

The repo imports GitLab exceptions from two different locations (gitlab top-level in
GitLabProvider vs gitlab.exceptions in tests). This inconsistency makes the codebase harder to
maintain and increases upgrade fragility around exception types and mocking in the GitLab
integration.

Code

requirements.txt[25]

+python-gitlab==8.3.0

Evidence

After the python-gitlab major version bump in requirements.txt, the codebase still uses two
different import paths for the same exception class family, which complicates refactors and tests
and can create subtle mismatches in exception handling/mocking.

requirements.txt[22-35]
pr_agent/git_providers/gitlab_provider.py[8-12]
tests/unittest/test_gitlab_provider.py[3-7]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
GitLab exception imports are inconsistent: the provider imports `Gitlab*Error` from the top-level `gitlab` package, while tests import from `gitlab.exceptions`.

### Issue Context
This PR upgrades `python-gitlab` to a new major version, so standardizing import paths reduces future churn and makes mocking/exception catching consistent.

### Fix Focus Areas
- requirements.txt[25-25]
- pr_agent/git_providers/gitlab_provider.py[8-12]
- tests/unittest/test_gitlab_provider.py[3-7]

### Suggested change
- Pick one canonical import path (prefer `gitlab.exceptions`) and update both production code and tests to use it consistently.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Previous review results

Review updated until commit 81f55cd

Results up to commit cccbc4e

🐞 Bugs (1) 📘 Rule violations (0)

1. No Python 3.14 CI 🐞 Bug ☼ Reliability

Description

The PR’s stated goal is Python 3.14 compatibility, but the repo’s automation (publish workflows and
Docker builds) is pinned to Python 3.12 and there is no CI job that installs/runs on Python 3.14, so
3.14-specific dependency/install regressions will not be caught automatically.

Code

requirements.txt[R28-34]

+tiktoken==0.12.0
ujson==5.8.0
uvicorn==0.22.0
tenacity==8.2.3
gunicorn==23.0.0
pytest-cov==7.0.0
-pydantic==2.8.2
+pydantic==2.13.3

Evidence

The PR changes runtime dependency pins in requirements.txt, but the existing automation paths that
build/install the package are configured to use Python 3.12 only, so they do not validate the PR’s
Python 3.14 compatibility goal.

requirements.txt[28-34]
.github/workflows/publish.yml[70-74]
.github/workflows/publish.yml[147-150]
docker/Dockerfile[1-10]
docker/Dockerfile.lambda[1-9]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
This PR updates dependency pins (tiktoken, pydantic) to achieve Python 3.14 compatibility, but current automation paths only run on Python 3.12, so Python 3.14 install/runtime issues won’t be detected automatically.

### Issue Context
The publish workflow and Docker images are pinned to Python 3.12. There is no workflow that installs the package (or at least resolves/install dependencies) on Python 3.14.

### Fix Focus Areas
- .github/workflows/publish.yml[70-74]
- .github/workflows/publish.yml[147-150]
- docker/Dockerfile[1-10]
- docker/Dockerfile.lambda[1-9]

### What to change
- Add a CI job (either in an existing workflow or a new one) that runs on Python 3.14 and at minimum performs:
 - `pip install -r requirements.txt`
 - `pip install .`
 - (optionally) a minimal import smoke test (e.g., `python -c "import pr_agent"`)
- Keep existing Python 3.12 jobs; this is additive validation for the PR’s stated compatibility target.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-free-for-open-source-projects]

Persistent review updated to latest commit 81f55cd

[naorpeled]

Hey @donbowman,
is the gitlab dependency bump mandatory after upgrading tiktoken and pydantic? 🙏

[donbowman]

i was not able to get the tool to work with my self hosted gitlab 18.11 without all 3.
the pydantic/tiktoken prevented use of py3.14 (i'm on ubuntu 26.04 which uses py3.14 by default, and was testing there).
the gitlab dependency, without updating that, i was getting a syntax error using the git api.

i don't think the python-gitlab dependency relates to py3.14, i think it relates to gitlab version.

with those changes its working reliably for me.