Skip to content

[Discussion] Abandon the gitlab CLI #708

New issue
New issue
Closed
Closed
[Discussion] Abandon the gitlab CLI#708

Description

@gpocentek
gpocentek
opened on Feb 22, 2019

The CLI is not in a good shape today, compared the rest of the library. Alternatives exist and seem to do a better job.

@max-wittig and I don't use the CLI, and don't have much to improve it so we are considering removing it from the python-gitlab code.

The decision is not made, and we hope to get some feedback from users in this issue.

Activity

  1. carleski commented on Feb 22, 2019

    @carleski
    carleski
    on Feb 22, 2019 via email

  2. max-wittig commented on Feb 22, 2019

    @max-wittig
    max-wittig
    on Feb 22, 2019
    Member

    Like mentioned above, we haven't made a final decision yet. But https://github.com/michaellihs/golab seems to be pretty good.

  3. xarx00 commented on Feb 25, 2019

    @xarx00
    xarx00
    on Feb 25, 2019
    Contributor

    I was just about to fill a couple of bugs in the gitlab CLI. They can be fixed easily.

    What exactly is meant by "not in a good shape"? Does it mean that the code is so buggy that it is not worth fixing? Or that there are some bugs but no one to fix them? Or that the CLI API is incomplete?

    If the CLI is in relatively good shape but some functionalities are missing or do not work because of simple bugs, then I'd vote for fixing them and letting the CLI alive.

    I actually found your project a couple of days ago because I was searching for a command-line gitlab client. I like yours, especially because it is written in python which I know (in contrast to ruby or go).

  4. max-wittig commented on Feb 25, 2019

    @max-wittig
    max-wittig
    on Feb 25, 2019
    Member

    Thanks for your opinion on this. The thing about CLI programs is that they are language independent and we're just two people maintaining this library (and neither of use uses the CLI). It would be cool, if we would get more people to help here.

  5. xarx00 commented on Feb 25, 2019

    @xarx00
    xarx00
    on Feb 25, 2019
    Contributor

    I was shortly looking at golab docs, and I'm missing such basic functionality like listing groups hierarchy. However, I haven't installed golab yet, so maybe golab shows the group hierarchy in its console output. But the docs for command "golab group ls" do not suggest anything like that.

  6. gpocentek commented on Feb 27, 2019

    @gpocentek
    gpocentek
    on Feb 27, 2019
    ContributorAuthor

    @xarx00 here is a list of bugs if you want to look into fixing the CLI: https://github.com/python-gitlab/python-gitlab/issues?q=is%3Aissue+is%3Aopen+label%3Acli

    We can of course help if you have questions :)

    Thanks!

  7. jamesquilty commented on Apr 10, 2019

    @jamesquilty
    jamesquilty
    on Apr 10, 2019

    I'm afraid I have no capacity to contribute, but I do use the CLI and I'd like to see the functionality preserved if possible. I'd much rather install a single library with a unified conceptual approach than have to install two packages which are based on different languages and, inevitably, different conceptual approaches to the CLI.

  8. gpocentek commented on Jun 8, 2019

    @gpocentek
    gpocentek
    on Jun 8, 2019
    ContributorAuthor

    Hi all,

    Not much progress on this in the last 3 months. Here is the status:

    • basic CLI stuff works OK
    • we have a bunch of open bugs, and some CLI commands don't work at all
    • CLI help is not good
    • we agreed that we need switch to another CLI lib, argparse is not good enough for what we need
    • I had a look at other CLI projects, most (all?) of them are not actively maintained

    Today the CLI and lib are tightly linked (plenty of attributes defined in the python classes), and the CLI code uses lib introspection to handle argument parsing. It is painful, and doesn't work well. I think we should keep the lib simple since it works fine this way, and we should move the "complexities" (types, mandatory/option arguments, ...) to the CLI, where it makes more sense.

  9. max-wittig commented on Jul 25, 2019

    @max-wittig
    max-wittig
    on Jul 25, 2019
    Member

    Let's preserve the CLI, even though it might be worse than something like https://github.com/michaellihs/golab, but people still use the python-gitlab CLI a lot.

  10. max-wittig
    closed this as completedon Jul 25, 2019
  11. bufferoverflow
    reopened this on Oct 17, 2019

  12. chrisoldwood commented on Jan 30, 2020

    @chrisoldwood
    chrisoldwood
    on Jan 30, 2020

    I recently stumbled upon this project as I was looking for a tool to help me do some basic GitLab admin from the command line (most notably checking up on runners and seeing job failures).

    The fact that there were extensive docs to go hand-in-hand with the API docs gave me a warm feeling. I found the CLI easy to pick up largely because of the docs, although the help for the entire list of resources is a little unwieldy and I see a couple of issues already raised around that. Aside from that it's been pretty easy from using the docs to work out what --scope and --sudo are about. Yes, they could be nicer, e.g. listing the values for --scope but it's not a showstopper for me.

    My only real stumbling block with the CLI was the sparsity of the output in the default (legacy) mode. I was confused by the lack of properties on display and spent ages looking into the --fields argument to try and get more data out before finally realising (after trying the JSON output) that that was all there really was to see. I'm not sure what role the legacy output plays but I'm not sure it's a good default or useful. (I'm used to the Format-List and Format-Table outputs in PowerShell for initial exploration and simple summaries.)

    Once I had the JSON output it was just a hop, skip, and jump to add some jq and column magic to give me the tabular output I wanted (with the essential attributes). I've now wrapped these one-liners up into some simple bash scripts that anyone can easily consume.

    While the library is nice to have as a fallback I do not really know Python and so the CLI is more useful to someone like myself coming from the curl/bash angle. I've found it much easier it explore the API by using gitlab --help | grep --color=always <resource> and then drilling into the specific resources and verbs with --help before turning to the GitLab API docs for the finer details.

    I'm just one data point but I thought I'd add my vote for it's usefulness as it stands (#593 notwithstanding 🙂). Thanks again for all your hard work, whatever happens.

    Note: I was not even aware of golab until reading this thread. I'm going to try it out as Go is something I'm more au fait with but it looks like I've still got to do the jq dance so I'm not sure what else it'll buy me.

  13. xarx00 commented on Mar 21, 2020

    @xarx00
    xarx00
    on Mar 21, 2020
    Contributor

    If you are interested, you may look at my fork https://github.com/xarx00/python-gitlab. I fixed some bugs, improved the outputs and implemented various new functions there. The new functions are mainly related to the correspondence between the remote GitLab and its local copy.

    But I had to change the core slightly, so this fork is now incompatible with the original and cannot be merged easily. If there is enough interest, I can make it mergeable, but the behaviour of the CLI changed a little, which might be a problem for the python-gitlab maintainers. You should be aware, however, that I'm not going to maintain an official clone if this fork won't be merged in to the original python-gitlab.

    If you're going to test it anyway, you'll need to create a .gitlab file in the root directory of your Gitlab subtree copy. It should look like this:

    [global]
default = origin
base_group = BI/ESB
timeout = 5
api_version = 4

[origin]
url = https://gitlab.yourdomain.com
ssl_verify = W:\MyProject\config\ca-bundle.crt
private_token = ZX3252U9D5xTV5DUQUzT

    The base_group property must contain the gitlab path for the root folder of the local copy. (The idea is that you have a local copy of a subtree structure of the remote Gitlab repo. It is not necessary that all git repos from this subtree are copied locally.) Use the -c @ command-line parameter to refer to the .gitlab file (if your current directory is within the local tree), or use -h for help. The main new command-group (command-object) is named bulk. So, for example

    gitlab -c @ bulk pull --group-path BI/ESB/dev/services
gitlab -c @ bulk status --group-path BI/ESB/dev/services --no-git-errors=true --no-ci-errors=true

    Tested on Windows, only.

  14. bufferoverflow commented on Mar 23, 2020

    @bufferoverflow
    bufferoverflow
    on Mar 23, 2020
    Member

    @xarx00 Please contribute here if you have some fixes.

  15. xarx00 commented on Mar 25, 2020

    @xarx00
    xarx00
    on Mar 25, 2020
    Contributor

    I've already contributed several fixes. The other fixes would require more or less substantial changes in the core. I don't remember the details, as it is already several months since I made last changes. But that was why I forked, because I was unable to make the fixes and improvements backwards compatible.

    My aim was to add functionality related to local copy of the remote repository, hence the functionality that is not part of the GitLab REST API. I needed to "bend" some functionality in python-gitlab in order I was able to do that. And, along the way, I did also several fixes and improvements.

  16. nejch
    closed this as completedon May 17, 2021
  17. python-gitlab
    locked and limited conversation to collaborators on May 17, 2021
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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions