You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the problem, including code/CLI snippet
gitlab user-project list --user-id 42 fails.
A similar issue has previously been reported in #881 .
Expected Behavior
List of projects owned by the current user are shown.
Actual Behavior
Impossible to list objects ('user_id') is printed.
Specifications
python-gitlab version: 3.14.0
API version you are using (v3/v4): v4
Gitlab server version (or gitlab.com): GitLab Community Edition 15.11.0
Notes
So I solved my particular problem by hard-coding my user-id in gitlab/v4/objects/user.py l. 641 (in the UserProjectManager list method). Obviously not a general solution, but maybe it helps to track down the error or someone else who comes across this. :)
Furthermore, what I really don't understand is why no KeyError is raised when the format string is processed.
Looks like a regression from ac1c619, as we started deleting kwargs for other reasons, so by the time we're doing do_list() in the CLI the user_id is already gone.
@w7089 it's mostly because of how the CLI constructs the methods called. Some arguments get passed around in run() and get cleaned up erroneously in this case because we use a custom method that expects the arguments used a little differently from our normal mixins.
Activity
nejch commentedon May 1, 2023
Looks like a regression from ac1c619, as we started deleting kwargs for other reasons, so by the time we're doing
do_list()in the CLI theuser_idis already gone.w7089 commentedon May 3, 2023
It's interesting that there's no issue with API, only with CLI.
Below code
gets and prints the project list without any issue.
nejch commentedon May 3, 2023
@w7089 it's mostly because of how the CLI constructs the methods called. Some arguments get passed around in
run()and get cleaned up erroneously in this case because we use a custom method that expects the arguments used a little differently from our normal mixins.w7089 commentedon May 24, 2023
@nejch I believe the fix is as simple as adding
self.mgr._from_parent_attrs = self.parent_argshere. I tried locally and the issue got resolved.If it's acceptable, i'll open a PR after testing of other managers.
I may be wrong as well and miss something as it's my first ever PR here.
JohnVillalovos commentedon May 28, 2023
Please feel free to open a PR if you think you have a valid fix. Thanks.
JohnVillalovos commentedon May 28, 2023
I think the main reason for this is because of
UserProjectManagerand the fact that thepathhas to be regenerated.python-gitlab/gitlab/v4/objects/users.py
Lines 575 to 641 in 86eba06
So maybe the idea of setting the parent attributes is correct but I'm not sure.
w7089 commentedon May 31, 2023
ok, opened the pull request, 2 previous PRs can be deleted, they are not relevant.
w7089 commentedon Jun 30, 2023
@JohnVillalovos any feedback on the PR?
JohnVillalovos commentedon Jul 6, 2023
I'll try to look at it this week. Sorry for the delay.
fix(cli): add _from_parent_attrs to user-project manager (#2558)