[HN Gopher] Gh-dash: A beautiful CLI dashboard for GitHub
___________________________________________________________________
Gh-dash: A beautiful CLI dashboard for GitHub
Author : robenkleene
Score : 233 points
Date : 2024-05-28 00:25 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| alchemist1e9 wrote:
| Looks very nice!
|
| Slightly related question - is there any self-hosted github API
| compatible solution? I'm pretty sure the answer is no, but
| figured I ask.
| eyegor wrote:
| +1 for gitlab support -- self hosted gitlab (or gitea) is
| probably the most popular one, since self hosted github is very
| pricy
| Galanwe wrote:
| Would be nice to have it for Github Enterprise for sure!
| pvcnt wrote:
| Shameless plug: I developed a similar project that is Web-based
| (source [1], demo [2]) and supports having multiple connections
| configured. Both github.com and GitHub Enterprise are
| supported. Other backends (e.g., GitLab, Azure DevOps) could be
| added in theory. I started this because at work, we use no less
| than 2 instances of GitHub Enterprise, in addition to
| github.com.
|
| It is a client-side application, meaning that it is very simple
| to host (no backend required).
|
| [1] https://github.com/pvcnt/reviewer
|
| [2] https://reviewer.pages.dev
| argulane wrote:
| Gitea API is pretty close to GitHub
|
| https://docs.gitea.com/
| alchemist1e9 wrote:
| gh-dash should add Gitea API support!
|
| I've used gogs a lot in the past and it's worked very well
| for my use case which Gitea is a fork of.
|
| It would be great to have a fully self-hosted setup with this
| tui interface.
| rajishx wrote:
| gitea, forgejo (but not 100% api compatible)
| danielvaughn wrote:
| I'm really loving this whole trend of well-designed TUI
| applications that Charm has enabled.
| oefrha wrote:
| Funny that Go is top notch in the TUI space thanks to Charm
| while the GUI landscape is absolutely abysmal (Wails is the
| only thing that's okay).
| endgame wrote:
| I feel like this "missing middle" is common to a lot of
| language communities these days. Devs writing for themselves
| are often happy to make cool TUIs, and devs writing for "end
| users" are often writing webapps.
| oooyay wrote:
| If you know Typescript and have a component framework you
| like it's about the same level to write a TUI in Charm as
| it is to write something in Wails. I kind of alternate
| between them.
| theshrike79 wrote:
| I've heard some good things about Fyne:
| https://github.com/fyne-io/fyne
|
| Doesn't do native-looking software, but the APIs don't look
| that bad.
| oefrha wrote:
| I've used it twice, both times regretted and rewrote in
| Wails (that is, back to a web view for UI). Problems not
| limited to:
|
| - (Last I checked, which is <1yr ago) Text rendering is
| fundamentally done wrong, it can't access any system font,
| can only use the built-in font, or exactly one custom font
| you bundle. Good luck supporting any user-generated or web
| content from people who don't use the Latin script.
|
| - Very limited selection of widgets, a problem common to
| all but a few native frameworks.
|
| - Very limited styling options for the small selection of
| widgets.
|
| - Looks terrible. Okay for personal/internal stuff,
| definitely don't want to ship to end users. (Obviously
| subjective.)
| theshrike79 wrote:
| I need to look into Wails, thanks for the tip.
|
| My use-cases would be perfect for a TUI, but I need to be
| able to display pictures and videos, so I'm stuck with a
| GUI :)
|
| Tried to do a web ui + local backend setup, but that
| didn't go too well.
| withinboredom wrote:
| You can display videos and pictures in the terminal...
|
| mpv --no-config --vo=tct /my/video.mp4
| oefrha wrote:
| If you want to play videos at 32p...
|
| High resolution images on the other hand is supported
| natively in many terminals (sixel protocol, iTerm 2
| protocol, etc.).
| rigid wrote:
| https://textualize.io for python isn't bad either. (In case
| you don't like static builds like me.)
| pdimitar wrote:
| OK, that is going straight to my "random statement of the
| day" collection:
|
| "I don't like static builds"
|
| ~ rigid@HN
|
| --
|
| Some things really catch me off-guard.
| withinboredom wrote:
| For people with super-custom kernels, static builds might
| use a custom syscall thinking its a syscall for a newer
| kernel. Further, it might not support their kernel
| version (libc-to-syscall mismatch).
|
| Then there's the fact that I might have compiled
| libraries with certain options that a static compilation
| won't get, ever (such as native CPU instructions or other
| optimizations).
|
| Even worse, static builds mostly use musl as the libc
| implementation, for which there are many issues (DNS
| issues, the fact that most openssl library tests don't
| pass and are disabled). I wouldn't trust musl/alpine/et
| al in production for "serious" things.
|
| Static builds are __convenient__, but they shouldn't be
| the default.
| rigid wrote:
| They suck to maintain.
|
| I love the fact that you can just update one single
| openssl lib and all installed apps use the updated
| version after a restart.
|
| Static builds have their legitimate use-cases so maybe
| change that to " _mandatory_ static builds ". (iirc go
| support for dynamic linking is worked on and will become
| stable eventually)
| kbd wrote:
| More than "not bad", Textual is probably best in class for
| TUIs atm, but I wish Python had static builds! Even
| Javascript can build executables now with Bun!
| oefrha wrote:
| JS executables with deno or bun aren't terribly different
| from pyinstaller executables. Of course they've been made
| more convenient by being bundled with the toolchains.
| rigid wrote:
| > I wish Python had static builds!
|
| while unusual in the "python world", there are more or
| less well supported ways:
| https://www.askpython.com/python/examples/compiling-
| applicat...
|
| i'm sure go will support dynamic linking aswell sooner or
| later
| theshrike79 wrote:
| I'm guessing this is the Charm you're referencing:
| https://charm.sh ?
| danielvaughn wrote:
| Correct, sorry yeah I should've linked to it.
| renewiltord wrote:
| Thanks for mentioning this, guys. Pretty slick looking
| toolkit. I always wondered how everyone these days has such
| fancy looking CLIs.
| kreelman wrote:
| Has anyone thought of doing something like this for Gitlab?
|
| I'll browse the code and see how readily it could be converted
| over to working on Gitlab.... also, Gitlab has a GraphQL API
| available to get at various bits of data surrounding a repo.
|
| I've not looked at this code yet, perhaps it does something
| similar....?
| locusofself wrote:
| I wish I had this for Azure DevOps. Work at MSFT and don't have a
| choice in the matter.
| alternatex wrote:
| Bit misleading. Working at MSFT doesn't mandate to use ADO for
| hosting code. Plenty of teams host their projects on GitHub.
| DiggyJohnson wrote:
| It's not misleading. The obvious assumption is that GP works
| for a team at Microsoft that uses ADO and not Github.
| jayknight wrote:
| To be fair, it does read like "Work at MSFT and [therefore]
| don't have a choice in the matter."
|
| It's not an institutional policy (MS owns github after
| all), so it would have been more clear to say
|
| "Work on a team that uses ADO and don't have a choice in
| the matter."
| burgerrito wrote:
| Possibly an unpopular opinion: TUI application should work out of
| the box, or in other words, it shouldn't need another font
| installation (NerdFont in this case) to run and render properly.
| One of the TUI app that does this well is Helix editor and I love
| it.
| strathos wrote:
| Somewhat related, this is the main reason why I settled on
| using Wezterm as my terminal. It comes with Nerd Fonts pre-
| bundled.
| behnamoh wrote:
| That seems like an unreasonably over the top reason to switch
| terminals while you literally can brew install any font.
| godelski wrote:
| I really agree here, as someone who uses nerd fonts a lot[0].
| There should always be a default without nerd fonts.
|
| That said, what does it actually look like without? The docs
| say "render properly". I haven't tried it yet, let alone
| without nerd fonts.
|
| That also said, I'd give this one a bigger break than most. If
| you're doing development work on a machine you probably got
| decent control and at least enough space to install fira.
|
| [0] I suspect there are two types of people that are terminally
| terminal: those that are just in their own shells and can
| always control their full environment and those that work in
| many machines. I'm the latter, but I tend to notice the latter
| are also the former, but make different choices because of
| this, or at least smarter dotfiles that will change things
| based on environment or (like me) have source install scripts
| (you can always build a program locally ;) I'm glad people live
| in the shells, but I hope people making TUIs can realize that
| there's a bunch of us that have to move machines constantly.
| bee_rider wrote:
| There's something a little funny about a CLI interface to GitHub,
| a website based on making it easier to use... git, a CLI program.
|
| Which isn't to poo-poo the project, GitHub adds a bunch of extra
| features so I can see why someone might want to build up on it.
| It's just funny, the winding path our files take to get to our
| eyeballs.
| rejschaap wrote:
| The funny part is that we decentralized version control with
| git and then centralized software development in GitHub
| cqqxo4zV46cp wrote:
| Not that funny when "we" means a different thing in each of
| its uses.
| yavor-atanasov wrote:
| We like creating decentralised technologies to then graviate
| around centralised services built on top. The Internet was
| meant to be decentralised (it still is in terms of the
| protocols that make it work), but then we ended up consuming
| very much centralised services. Bitcoin's decentralised in
| terms of technology, but then we are centralising in terms of
| exchanges, wallets etc.
|
| I guess the decentralisation aspects of a given technology
| just means it's a resilient building block. And since the
| only way we make sense of things nowadays is through markets,
| it's inevitable we starting building and consuming
| centralised services.
|
| I'm not saying centralisation is good or bad btw, but I do
| share the irony in your reply, mostly because I find it funny
| when a new tech is being sold as new way of doing something
| in a decentralised way.
| setr wrote:
| Decentralization mainly grants
| flexibility/customization/freedom, but generally you don't
| really care about this -- freedom only really matters when
| you can't do the thing you're trying to do.
|
| If everything is already covered without such freedom, or
| you don't care about what's not covered (or failed to
| conceive it), then you don't really mind having the freedom
| or not. It doesn't change much.
|
| Gmail is a good email client -- email being decentralized
| is only relevant to me if I wanted to get off gmail to go
| to say fastmail. But if I didn't, what do I care whether
| the underlying protocol is centralized or not?
| bee_rider wrote:
| > freedom only really matters when you can't do the thing
| you're trying to do.
|
| Disagree, or at least think there's a need to clarify.
| This makes it look like a freedom is only occasionally
| relevant.
|
| This kind of freedom derived from decentralization also
| exists as a persistent threat against bad behavior. If
| users _can_ leave and bring their stuff with them, that
| constrains the choices that the platform can even
| consider.
|
| Attempts to centralize should be seen as strategic
| attempts to change the landscape in a way that makes it
| easier to exploit users.
| dreamcompiler wrote:
| We did the same thing with the Web but we prefer Google and
| Facebook.
|
| We did the same thing with email but we prefer Gmail.
|
| We did the same thing with Usenet but we prefer Reddit.
|
| We did the same thing with IRC but we prefer Slack.
|
| We did it with shitcoins but we prefer Coinbase.
|
| Turns out people really don't care much for pure
| decentralization. There's money to be made recentralizing
| decentralized whatever.
| bee_rider wrote:
| It is way more difficult to exploit users of a
| decentralized service, because they can just go to another
| host.
| williamdclt wrote:
| People don't care about whether their tools are decentralized
| or centralized (apart from a few principled individuals).
| They care about the UX of the tool, and so far centralised
| options have won on UX. I'm not sure how much of that is due
| to being centralised, rather than being due to companies
| investing in UX to gain market share preferring a centralised
| model.
|
| Ofc centralised/decentralised is also part of the UX (what
| happens when the centralised service goes down), but so far
| it's not been a net win for decentralised.
| bathwaterpizza wrote:
| That's the way you see GitHub? for me it's a repo hosting
| platform, the UI is just a pleasantly
| bee_rider wrote:
| I don't use the site much at all, but it isn't really a
| matter of how I see the site--they clearly added features
| like issue tracking, commenting, and CI, and people use those
| features.
| 3D39739091 wrote:
| The point is that Github is not just a web-based graphical
| client for Git.
| powerapple wrote:
| Love it, thank you! I couldn't get the help screen by '?' though.
| I can escape the input box with esc, but then '?' will refocus on
| the search box again.
|
| EDIT: got it now, not sure why it didn't work before
| peter_l_downs wrote:
| Looks cool. A few thoughts:
|
| - Why? Strongly suggest updating the README to explain why this
| is useful, or what kind of workflow makes this useful. Just a
| list of features isn't that compelling to me because I'm not sure
| I want it.
|
| - Because this is a gh cli extension, and not a standalone
| program, searching is unfortunately going to be fairly slow.
| There doesn't seem to be any local caching or syncing of the
| Github data.
|
| - Not really a user-impacting issue, just a fun fact: because the
| pagination is handled via Graphql's PageInfo support in their
| Graphql API, you'll never be able to page through more than 1000
| results in a given response.
|
| - Authors might consider linking to
| https://docs.github.com/en/search-github/searching-on-github in
| the README, it makes figuring out how to write a custom search a
| lot easier.
|
| - I'm happy to see XDG_CONFIG_HOME support, but the authors
| should consider also checking for a config file in
| $RepoRoot/.config/gh-dash/ and $RepoRoot/.gh-dash/, so that a
| single config could be more easily shared by members of a team
| who all check out the same repository.
|
| I'm working on something like this (customizable filter views for
| Github; quickly drill down into PRs by different authors,
| affecting different files, across multiple repos, filtered by
| regex search on the changed files / pr body / pr title / pr
| comments) but based in the browser, not a TUI. The primary goal
| of my project is to help engineering leaders understand what is
| actually getting shipped, and communicate that to other non-
| technical leaders. If anyone is interested in being a beta tester
| let me know, I'm hoping to have a release publicly available at
| the end of this week!
| mb7733 wrote:
| > Why? Strongly suggest updating the README to explain why this
| is useful, or what kind of workflow makes this useful. Just a
| list of features isn't that compelling to me because I'm not
| sure I want it.
|
| I don't mean to speak for the author, but: The 10 seconds it
| took for the GitHub web UI to load the homepage of this project
| is a great justification for its existence!
| peter_l_downs wrote:
| I hear that, but this is fetching data from the Github
| graphql API the same way that the website does, so if you're
| getting slow responses from their servers this won't be any
| faster.
| mb7733 wrote:
| There is a lot of other stuff that gets loaded and parsed
| when you visit the site. I see 151 requests and get a
| DOMContentLoaded of 27.51 seconds. The slow requests aren't
| between me and the GQL API as far as I can tell.
| inhumantsar wrote:
| I'd be keen to check that out! I've been toying around with
| similar thoughts the last year or so. Metrics and dashboards
| aren't enough and the GH site doesn't really have an org-level
| view.
| peter_l_downs wrote:
| not sure how to contact you, but if you email me i'll follow
| up once i have something available for testing! (my email is
| in my bio)
| autoexecbat wrote:
| > Why?
|
| Sometimes it's nice to just stay in tmux
| dcre wrote:
| This is really cool!
|
| I have something similar just for checking out PRs in a single
| bash function, powered by gh and fzf: function
| ghpr() { gh pr list --limit 100 --json
| number,title,updatedAt,author --template \ '{{range
| .}}{{tablerow .number .title .author.name (timeago
| .updatedAt)}}{{end}}' | fzf --height 25% --reverse |
| cut -f1 -d ' ' | xargs gh pr checkout }
|
| Screenshot:
| https://github.com/oxidecomputer/console/assets/3612203/2805...
| achristmascarl wrote:
| speaking of fzf, i have an alias for checking out branches
| using it + git: alias gbs="git branch
| --sort=-committerdate | fzf | xargs -I{} git checkout {}"
| mtmk wrote:
| Very cool. Coincidentally, I was looking into starting to use
| Midnight Commander (again). When I run it in a repo, I still see
| my overall PRs, etc. Is there an option to get it to focus on the
| current repo?
| jonathankoren wrote:
| I guess we've gone full circle to back to curses like UIs in
| terminals now.
___________________________________________________________________
(page generated 2024-05-28 23:01 UTC)