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.
