Repository navigation
[Discussion] Abandon the gitlab CLI #708
Description
Activity
- I'd be a bit sad to see this go. We're just getting ready to launch a GitLab instance on our campus, and for my team, having quick CLI tools to help with some administrative work has the potential to be extremely helpful, as we've already seen with some of our other services like Google and Box. If the CLI is to be removed, could anyone make a suggestion as to a good alternative?…On Fri, Feb 22, 2019 at 9:51 AM Gauvain Pocentek ***@***.***> wrote: 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 <https://github.com/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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#708>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AjpHj7QsBuDJTl4srbYf3E6oDvzFPsfIks5vQAP1gaJpZM4bJwDk> .-- *Rob Carleski* ITS Collaboration Services University of Michigan 734.764.2777Reacted by B
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
--scopeand--sudoare about. Yes, they could be nicer, e.g. listing the values for--scopebut 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
--fieldsargument 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 theFormat-ListandFormat-Tableoutputs 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
jqandcolumnmagic 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/bashangle. I've found it much easier it explore the API by usinggitlab --help | grep --color=always <resource>and then drilling into the specific resources and verbs with--helpbefore 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
golabuntil 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 thejqdance 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 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
.gitlabfile 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 = ZX3252U9D5xTV5DUQUzTThe
base_groupproperty 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.gitlabfile (if your current directory is within the local tree), or use-hfor help. The main new command-group (command-object) is namedbulk. So, for examplegitlab -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=trueTested 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.
- locked and limited conversation to collaborators
on May 17, 2021
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.