Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

What am I missing here?#2917

Unanswered
stdedos asked this question inQ&A
Jul 8, 2024· 1 comments· 3 replies
Discussion options

I am trying to probe thehttps://docs.gitlab.com/ee/api/merge_requests.html#get-single-mr API, and I thought I'd usepython-gitlab for this.

After some trying, I got to

gitlab -v --gitlab inst-gitlab project-merge-request get --project-id 15 --iid 15899

I expected "some kind of output". However, I only receivediid: 15899 - which I kinda new already 😕

I needed to add-v to see "some kind of output". Then, I noticed-o json, and I got something of what I wanted.

... However, why isn't that the default? I don't want to start a "default output format" religious war - butsome kind of output, that's not what I needed to spoon-feed in the first place

What am I missing here?

You must be logged in to vote

Replies: 1 comment 3 replies

Comment options

nejch
Jul 8, 2024
Maintainer

@stdedos in the legacy output (the default), the default behavior is to print out the ID and what we call the_repr_attr which is the human-readable attribute. It just so happens that merge request object on our end doesn't have a repr attribute defined (https://github.com/python-gitlab/python-gitlab/blob/main/gitlab/v4/objects/merge_requests.py#L155), so all you see is an ID. Ideally this would be the title, for example.

I'm not sure what the decision behind the short vs. verbose behavior was as it's before my time. YAML would probably make more sense and just print it all out, but that pulls in another (currently optional) dependency for the CLI.

You must be logged in to vote
3 replies
@stdedos
Comment options

... or JSON and avoid the extra dependency 🙃

Could we extend the config file with a global (and per-server?) optionformat = legacy | json | yaml?

@nejch
Comment options

nejchJul 8, 2024
Maintainer

I guess JSON is more for programmatic use so might not be the nicest output by default 😅 Yes, a global config option might be best actually.

@stdedos
Comment options

Yes, a global config option might be best actually.

I just "don't want to remember this" anymore 😅

Maybe I'm a minority, but I'm using the CLI solely as the "quick" version ofcurl... (trying to figure out how to build a query)

Legacy format (if extended) may make sense. Idk the amount of "ready formats" vs "not-ready" (like my command's case).

If not-ready is a majority, it's better IMHO to switch to YAML (if you are fine for the dependency).

Honestly, I was "mislead" thinking that I can pass posargs to the command and get the keys I wanted 😅

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
2 participants
@stdedos@nejch

[8]ページ先頭

©2009-2025 Movatter.jp