In CommitManager, using the path filter breaks the endpoint call

[Triss Jacquiot]

Description of the problem, including code/CLI snippet

The v4 API specifies a path filter attribute on the repository/commits/ endpoint¹; it also exists within this package's documentation². However, using it through the package appears to break the API call.

Here's a minimal reproducible example of the problem :

import gitlab

project_id = "gitlab-org/gitlab"
readme_path = "README.md"

gl = gitlab.Gitlab()

repo = gl.projects.get(project_id)

# Should work 
# Expected Call `/api/v4/projects/gitlab-org/gitlab/repository/commits?path=README.md`
# and return a list of commits about the readme file
repo.commits.list(path=readme_path)

# Actual call : 
# `/api/v4README.md` 
# and throws `gitlab.exceptions.GitlabListError: 404: 404 API Version Not Found`

I seem to have found the culprit line but I am not familiar enough with the codebase to fully understand this pattern ³.

Expected Behavior

The path keyword filter on gitlab.v4.objects.ProjectCommitManager.list() function should add the path keyword to the underlying API call.

Actual Behavior

The path keyword filter on gitlab.v4.objects.ProjectCommitManager.list() function replaces the actual api endpoint path on the underlying API call and breaks it.

Specifications

• python-gitlab version: 4.4.0
• API version you are using (v3/v4): v4
• Gitlab server version (or gitlab.com): gitlab.com

Footnotes

1. https://docs.gitlab.com/ee/api/commits.html#list-repository-commits ↩

2. https://python-gitlab.readthedocs.io/en/stable/api/gitlab.v4.html#gitlab.v4.objects.ProjectCommitManager ↩

3. https://github.com/python-gitlab/python-gitlab/blob/f6e8692cfc84b5af2eb6deec4ae1c4935b42e91c/gitlab/mixins.py#L241C1-L243C43 ↩

[John Villalovos]

Please look at https://python-gitlab.readthedocs.io/en/stable/api-usage.html

Search for query_parameters

Try using that.

[Nejc Habjan]

As @JohnVillalovos says this is because path conflicts with python-gitlab's own arguments. This can happen sometimes and we have query_parameters to avoid this. I'll close this as answered but feel free to reopen if you have any more questions! :)

[Triss Jacquiot]

Thanks for the workaround; however it doesn't feel completed to me yet --- I wouldn't expect providing query arguments as keywords to clash against python-gitlab's internal API, especially when the idiomatic usage of the wrapper uses keywords in the function's documentation 😅

Let's keep this open for a few days, lemme get around adding a warning about this in the docs, so future users can at least easily find the query_parameter argument :)