- have you tried lazyjj? I was thinking about giving it a go.
- I've been fighting the git CLI for over a decade and I've recently picked up lazygit so I can relate to this post. A good TUI has made git a joy to use and when I did try to pick up jj last year it seems like too much learning for too little gain.
I think git will be "good enough" version control for many years to come.
- HOCON is so overlooked but an almost ideal config language in my eyes. The only element I'm not 100% on is unquoted string values (the norway problem but not quite as bad since there isn't no/yes booleans), but even thats not too bad.
- A passkey import/export standard is in the works. Once I know I can backup everything in a keepass database I'll be much happier.
- Very similar to the koka language. I hope these effect systems become mainstream.
- Good: `mise prune --yes`
Mise tracks config files to make sure it doesn't delete used versions: `mise config ls --tracked-configs`
- I got excited when I saw the title, thinking it was local-first software advocacy. But I guess if local-first software advocacy gets me excited, then maybe I should turn off the screen and touch some grass.
- Mise has a very similar feature with its shebangs: https://mise.jdx.dev/tips-and-tricks.html#shebang
It makes throwing together a bash scripts with dependencies very enjoyable#!/usr/bin/env -S mise x xh jq fzf gum -- bash todo=$(xh 'https://jsonplaceholder.typicode.com/todos' | jq '.[].title' | fzf) gum style --border double --padding 1 "$todo" - Many OS's have their own (sometimes multiple) container technologies, but the ecosystem and zeitgeist revolves around OCI Linux containers.
So it's more cultural than technical. I believe you can run OCI Windows containers on Windows with no VM, although I haven't tried this myself.
- "Don't retract bookmark sub-menus after drag and drop" - The 17 year old issue (2008) was locked for comments recently, so I don't have any other way to celebrate. I've been subscribed to this issue for over half of my life. I can't say I really care about it anymore, but it feels momentous enough to warrant sharing.
- 10 points
- I've been using `git summary` from tj/git-extras for a while. It seems to do a similar job.
- The two most popular zsh plugins are total clones of this at 31k and 20k gh stars respectively. Not an award but certainly an indication of its success.
- > that uses a tool that is not yet in mise registry
Yes, you can directly get tools from npm/pypi/cargo/github-releases/asdf-plugins/vfox-plugins without anyone touching the mise registry. The registry is just a convenient index of short names e.g. "fzf@0.56.3" maps to ubi:junegunn/fzf@0.56.3 which will download the appropriate arch binary from the v0.56.3 junegunn/fzf GitHub release.
> if I want to provide a python runtime that is compiled slightly differently
The default uses precompiled binaries, but with one setting it can use python-build/pyenv under the hood, then all the pyenv env vars can be used to configure the build process.
- I feel like nix has been thoroughly discussed in this post already, so you're not the only guy.
> You don't need to mess around with shell hacks
Shell integration is optional, you can use `mise en` just like `nix-shell` or `nix develop`. You could also just invoke commands/scripts through mise tasks or mise exec.
> based on a string in one of several dozen dotfiles
The "Idiomatic" files like .nvmrc, .python-version, etc are supported but most people just use a mise.toml, which (a bit like flake files) contains all the config for the environment.
> but when tools are published through NPM or RubyGems or Crates or just on github that you have to run `go install` to get, then it's a bit of faff
And this is what mise excels at: `mise use npm:cowsay` or `mise use ubi:junegunn/fzf`
I think Nix/Guix are great, but also terrible. For me today, it's not worth the pain.
- Definitely, the CLI is more intuitive, and using paths instead of shims makes it faster and more reliable.
- `mise use uv`, there, I fixed it for you.
Mise actually has a great integration with uv, like auto venv activation.
- I like Devbox and I'm familiar with its features so I'll just mention the extras the mise has.
The ubi backend means I can use nearly any binary published on GitHub without needing to worry about a flake or nixpkgs. Just get the binary directly from the author. Same for many of the other backends https://mise.jdx.dev/dev-tools/backends/.
Tasks are very powerful, they can use dependencies, flags, args, completions, and watches. Also can be defined either as strings in the config or point to shell scripts or even python/node/whatever scripts.
The shebang trick is very fun for writing portable shell scripts https://mise.jdx.dev/tips-and-tricks.html#shebang
The fact that mise doesn't depend on nix is both a blessing and a curse. I have less tools available and I don't have the power of a package manager, but on the flip side I don't need to deal with the idiosyncrasies of nix.
- All the features are opt-in. I started using mise because I wanted something like asdf only without the bad UX, and mise can use asdf plugins.
For env vars, you don't need to load them into your shell if you don't want to. When you run a task, mise will make sure the env vars in your config are set, so thats not something you need to worry about.
I still use shell scripts like you describe, mise just supercharges them a bit. When I need to make sure my teammates have the tools in that script (like jq) installed, mise just ensure they are installed before running the command, as long as you declare them in your tools list.
If your setup works for you thats great.
Compare that to what we had in the late 00's and early 10's we went through prototype -> mootools -> jquery -> backbone -> angularjs -> ember -> react, all in about 6 years. Thats a new recommended framework every year. If you want to complain about fads and churn, hop on over to AI development, they have plenty.