Seriously. I’ve lost at least 100 hours of my life debugging whitespace in templated yaml. I shudder to think about the total engineering time wasted since yaml’s invention.
You blame YAML but I blame helm. I can build a dict in Python and dump it as YAML. I've painlessly templated many k8s resources like this. Why can't we build helm charts in a DSL or more sensible syntax and then dump k8s manifests as YAML? Using Go templating to build YAML is idiocy and the root of the issue here.
There's lots of advice on StackOverflow against building your own JSON strings instead of using a library. But helm wants us to build our own YAML with Go templating. Make it make sense.
I 100% agree. It’s not so much the yaml as it is the templating. I originally wanted to say “since the invention of yaml/jinja” in the parent comment because that’s what I’ve gotten most of my gray hairs from (saltstack templating). Go templates are not jinja but fundamentally the same thing - they have no syntax awareness and effectively are just string formatters.
I took out the part about templating because I thought it made my comment too wordy, but ended up oversimplifying.
The language supports templating (structurally, not textually), reuse/inheritance, typed properties with validation, and a bunch of other fun stuff.
They also have built in package management, and have a generated package that provides resources for simplifying/validating most kubernetes objects and generating manifests.
There's even a relatively easy path to converting existing YAML/JSON into pkl. Or the option to read an external YAML file and include it/pull values from it/etc (as data, not as text) within your pkl so you don't need to rebuild everything from the ground up day 1.
Aaaaand there's bindings for a bunch of languages so you can read pkl directly as the config for your app if you want rather than doing a round trip through YAML.
Aaaaand there's a full LSP available. Or a vscode extension. Or a neovim extension. Or an intellij extension.
The documentation leaves a bit to be desired, and the user base seems to be fairly small so examples are not the easiest to come by... but as far as I've used it so far it's a pretty huge improvement over helm.
Docker the company bet big on Swarm being the de facto container orchestration platform for businesses. It just got completely overshadowed by k8s. Swarm continues to exist and be actively developed, but it’s doomed to fade into obscurity.
You can scale the UI according to your preferences, but the real problem is that if your monitor’s ppi is not close to the macOS sweet spot of 220ppi (or an integer multiple thereof) you’re going to have aliasing issues with text and other high contrast elements.
I’m in the same boat with a lot of these tools, but bat is different in that it’s compatible enough to be safe to alias to the command it's replacing[1]. You can continue to use cat as usual, with the benefit of getting syntax-highlighted output.
[1]: Assuming you use the `--paging=never` flag in your alias as the README suggests.
In regards to the tenting not staying in place, put some threadlocker on the bolts. It does wonders. I got some threadlocker to stop my adjustable bar stool feet from slowly unscrewing themselves and getting wobbly every week and it's easily the best purchase I've made all year. Anytime I see a loose door knob, chair leg, tripod mount, or adjustment screw, I throw some threadlocker on there and never have to tighten it again.
Outside of holidays and special events, they do indeed choose randomly from a dialogue bank. There’s actually multiple dialogue banks, one for each villager personality type.
[Author here] The AI feature is their implementation on the server. I was just trying to see if the same could be implemented client-side as a good use case for the, as you say, experimental, Prompt API. (It's in origin trial, so you can use it already on production sites.) Downloading a model for just this use case is obviously stretching it. You'd use it if it's there, but not download it on purpose just for this convenience.
I've been using codecompanion.nvim[0] combined with mcp-hub.nvim[1]. Code Companion works well for interactive chat but falls short for agentic coding. It's limited to some pre-configured and user-defined "workflows" which are basically templated steps with prompts, actions, and loops.
I've been meaning to give avante.nvim[2] a try since it aims to provide a "Cursor like" experience, but for now I've been alternating between Code Companion for simple prompts and Claude CLI (in a tmux pane next to Neovim) for agentic stuff.