dyff - diff tool for YAML, which also nicely works with "kubectl diff" command for prettier output. Also, Jira and Gitlab CLIs comes in handy very often. (Not mentioning bat, jq and yq, as they are already covered in your video.)
I no longer used exa, jq, yq,... since I switched to nushell (those features are built-in). A non-POSIX shell, that requires a learning time and few adaptations, but far less than powershell. One of my favorite features is scripting where every exported functions (you can have several) have an "help" autogenerated from the signature of the function.
These are all, each and every one, fantastic tools. Though funny enough none of them are tools I'd put into devbox. They're too fundamental to my everyday, regular navigation and use of my terminal, and all need to be default and global (except maybe teller). Devbox can handle that, too, but honestly I mostly just use brew/brewfiles for the "Need everywhere" tools. I'm curious what people feel are common enough to put into devbox files, but not necessary enough to just have installed globally.
Spot on. I only have a few of those in devbox (ya, jq, and teller). All others are peanently installed on my machines. I put them in devbox.json for the demo used in the video only so that it's easier for people to follow along and reproduce what I did. Going back to your question... I tend to have the tools that are global and often used before I even reach the directory of a project installed directly. eza and zoxide would be two examples. Those that are project-specific are kept in devbox. Also, if I put an instruction in project readme, I tend to put the tools that are required to execute it in devbox. That's why, for example, I have bat installed globally and aliased to cat. That way i can instruct people to execute cat no matter whether they have bat or not.
@DevOpsToolkit Oh, for instructional purposes, I absolutely get that. It makes perfect sense. The more uniform you can make the experience of people coming in to try something, the greater chance of general success. It's hard to demonstrate the "normal" use-case of Devbox without getting too specific into any given project or its dependencies. Or at least I'm not sure how I'd do it.
I prefer toml file format over json... and I'd much rather write nix than json to be honest. numtide devshell and direnv are a potent duo. and the devshell.toml is much easier to use/read than json IMHO.
I love toml but, unfortunately, it is not as common as yaml and json. Nix, on the other hand, is too difficult for those not vested into it. If you're comfortable with it, great. For everyone else it is a bit hard to understand what's going on. I switched from direnv to teller since it solves the problem of secrets to env. vars. in a more elegant way.
Which are your favorite CLI tools?
dyff - diff tool for YAML, which also nicely works with "kubectl diff" command for prettier output. Also, Jira and Gitlab CLIs comes in handy very often. (Not mentioning bat, jq and yq, as they are already covered in your video.)
k9s, of course!
@mtik000 k9s is awesome and the only reason I did not put it on that list is that i consider it a dashboard rather than a CLI.
dive : to analyse container image
kubectx/kubens
Saved so I can check out all the tools that I haven't used yet, thanks for the breakdown
Thank you for your creativity, you are very helpful
This is valuable, thanks a lot!
I no longer used exa, jq, yq,... since I switched to nushell (those features are built-in). A non-POSIX shell, that requires a learning time and few adaptations, but far less than powershell.
One of my favorite features is scripting where every exported functions (you can have several) have an "help" autogenerated from the signature of the function.
Nushell is very interesting. I've been using it on and off for a while but I am not (yet) sure that I'll stick with it.
Great video!
These are all, each and every one, fantastic tools. Though funny enough none of them are tools I'd put into devbox. They're too fundamental to my everyday, regular navigation and use of my terminal, and all need to be default and global (except maybe teller). Devbox can handle that, too, but honestly I mostly just use brew/brewfiles for the "Need everywhere" tools. I'm curious what people feel are common enough to put into devbox files, but not necessary enough to just have installed globally.
Spot on. I only have a few of those in devbox (ya, jq, and teller). All others are peanently installed on my machines. I put them in devbox.json for the demo used in the video only so that it's easier for people to follow along and reproduce what I did.
Going back to your question... I tend to have the tools that are global and often used before I even reach the directory of a project installed directly. eza and zoxide would be two examples. Those that are project-specific are kept in devbox. Also, if I put an instruction in project readme, I tend to put the tools that are required to execute it in devbox. That's why, for example, I have bat installed globally and aliased to cat. That way i can instruct people to execute cat no matter whether they have bat or not.
@DevOpsToolkit Oh, for instructional purposes, I absolutely get that. It makes perfect sense. The more uniform you can make the experience of people coming in to try something, the greater chance of general success. It's hard to demonstrate the "normal" use-case of Devbox without getting too specific into any given project or its dependencies. Or at least I'm not sure how I'd do it.
Great Top 10 list. Point of pronunciation: 🦇≠🍑
I prefer toml file format over json... and I'd much rather write nix than json to be honest. numtide devshell and direnv are a potent duo. and the devshell.toml is much easier to use/read than json IMHO.
I love toml but, unfortunately, it is not as common as yaml and json. Nix, on the other hand, is too difficult for those not vested into it. If you're comfortable with it, great. For everyone else it is a bit hard to understand what's going on.
I switched from direnv to teller since it solves the problem of secrets to env. vars. in a more elegant way.
I was using eza but now I'm using lsd (not the drug)
How could you upload so many videos in a week? 😅
I upload only one video a week, and that's very challenging. I don't think I could do more than one a week.
I prefer LSD (ls deluxe) to exa/eza
you forget k9s
I wanted to focus it on more general CLIs. K9s is certainly awesome and should be on anyone's list.
Eza is ok, but Exa is better
I thought that exa is not maintained any more.
@@DevOpsToolkit Wow, I stand corrected. Thanks!
# til
For pass / secret I use pass
Combine with direnv