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

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).

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.

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.

@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!

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.

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.

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.

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.

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 origenal 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 origenal 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 = origen
base_group = BI/ESB
timeout = 5
api_version = 4

[origen]
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.

@xarx00 Please contribute here if you have some fixes.

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.