Visitar URL original
CLI ignores end points that don't define managed RESTObject · Issue #3112 · python-gitlab/python-gitlab · GitHub
Skip to content

CLI ignores end points that don't define managed RESTObject #3112

Description

@igorp-collabora

Description of the problem, including code/CLI snippet

Certain end points like SideKiq are skipped by CLI parser because they don't manage any objects. This is because only RESTManager classes that defined the _obj_cls attribute are parsed for the endpoints.

I described this behaviour here: #3083 (comment)

Expected Behavior

All endpoints with managers are accessible.

Actual Behavior

Missing endpoints:

  • group-registry-repository: /groups/{group_id}/registry/repositories
  • project-audit: /projects/{project_id}/audit_events
  • project-iteration: /projects/{project_id}/iterations
  • sidekiq: None
  • user-identity-provider: /users/{user_id}/identities

This list is made by taking a diff between current main branch python -m gitlab --help and my quick experiment of adding all RESTManagers to the CLI parser.

Activity

  1. igorp-collabora commented on Jan 30, 2025

    @igorp-collabora
    ContributorAuthor

    The current parsing is incredible complicated and converts class names to string and then uses getattr on the gitlab.v4.objects. This means it is impossible to have a RESTManager not using f"{_obj_cls.__name__}Manager" name.

    My plan is to rework how the CLI discovers end points to eliminate the conversions to strings. By iterating over gitlab.v4.object module it is possible find RESTManager subclasses. This assumes that there are no dangling RESTObjects without managers but I think such classes would fail because CLI does getattr(gitlab.v4.objects, f"{self.cls.__name__}Manager").

    To implement the @cli.register_custom_action I would make this decorator keep a set of all functions passed to it. The CLI parser would use inspect.getmembers() on the RESTManager classes and check if any of the member functions are part of custom cli action set. This eliminates the need for cls_names= argument.

  2. igorp-collabora commented on Jan 31, 2025

    @igorp-collabora
    ContributorAuthor

    @nejch I experimented more with a discovery rewrite and there is another big issue I encountered. The RESTManager class and the RESTObject can have conflicting custom actions.

    For example, GeoNodeManager and GeoNode both have a status action. This creates a few conflicts on the required arguments as calling it from the manager does not require any id but calling it from object does. Also return types are different. The manager returns list of dictionaries but object returns a single dict.

    Not sure how to handle this. The current behaviour is to mash everything together which might make certain API point unaccessible.

  3. igorp-collabora commented on Jan 31, 2025

    @igorp-collabora
    ContributorAuthor

    After contemplating I think I will make it only register one action per action name per manager. This eliminates any conflict but will make the manager methods shadow the object methods.

  4. nejch commented on Feb 12, 2025

    @nejch
    Member

    Sorry for the delay @igorp-collabora, will have to read up on this a bit as I haven't touched the CLI in a while 😅

  5. github-actions commented on Jun 26, 2025

    @github-actions

    This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.
    As an open-source project, we rely on community contributions to address many of the reported issues. Without a proposed fix or active work towards a solution it is our policy to close inactive issues. This is documented in CONTRIBUTING.rst
    How to keep this issue open: * If you are still experiencing this issue and are willing to investigate a fix, please comment and let us know. * If you (or someone else) can propose a pull request with a solution, that would be fantastic. * Any significant update or active discussion indicating progress will also prevent closure.
    We value your input. If you can help provide a fix, we'd be happy to keep this issue open and support your efforts.

  6. github-actions commented on Jul 11, 2025

    @github-actions

    This issue was closed because it has been marked stale for 15 days
    with no activity.

    This open-source project relies on community contributions, and
    while we value all feedback, we have a limited capacity to address
    every issue without a clear path forward.

    Currently, this issue hasn't received a proposed fix, and there
    hasn't been recent active discussion indicating someone is planning
    to work on it. To maintain a manageable backlog and focus our
    efforts, we will be closing this issue for now.

    This doesn't mean the issue isn't valid or important. If you or
    anyone else in the community is willing to investigate and propose
    a solution (e.g., by submitting a pull request), please do.

    We believe that those who feel a bug is important enough to fix
    should ideally be part of the solution. Your contributions are
    highly welcome.

    Thank you for your understanding and potential future
    contributions.

    This is documented in CONTRIBUTING.rst
    https://github.com/python-gitlab/python-gitlab/blob/main/CONTRIBUTING.rst

  7. locked as resolved and limited conversation to collaborators on Jul 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions