logoalt Hacker News

Mise: Dev tools, env vars, task runner

422 pointsby ksec12/07/2024182 commentsview on HN

Comments

banseljaj12/08/2024

I started using mise back when it was still called rtx. I was a little annoyed by asdf's quirks and having it replicate that behavior while being faster and less intrusive in my shell configuration was great.

Since then, mise has folded in two capabilities that I needed the most: Task Running and Env Vars.

Overall, it has been a fantastic experience for me. I love how the developer has spent a lot of time ensuring compatibility with existing tools while still building future capabilities.

I will add one thing that I knew I needed but couldn't find anywhere was added through the recent backends feature. I do a lot of trust and R development and there are dev tools that I need installed that I don't use as libraries, just the binaries. It was a problem making sure that those dependencies were installed in a new environment. Now, it's just so easy: I list those in my `mise.toml` file, and that ensures they are installed and installable.

show 2 replies
aaronbrethorst12/08/2024

I recently switched to Mise for all of my JS, ruby, python, and java sdk management needs, and I’ve been delighted with it so far. Not having to install RVM, NVM, some toxic brew of python installers until I get a working python environment, and SDKMan has been such a breath of fresh air.

show 2 replies
syhol12/08/2024

I'm using it to unify my teams toolchain without resorting to nix or running everything in docker.

I still use docker to run services and I still like the idea of nix, but the DX of mise is too good. Tasks are really nice too, all my repo scripts now have completions.

show 1 reply
RobT7k12/09/2024

I'd really like a better idea on Windows support for mise. Especially for development using WSL. It seems like it probably works there, but the docs are pretty slim.

> Note that Windows support is very minimal for now.

https://mise.jdx.dev/installing-mise.html#windows

BiteCode_dev12/08/2024

My experience with such tools is that when you do everything, you don't do anything right.

The chances that it doesn't leak greatly the underlying abstraction and creates troubles to figure it out when it will invariably fail is zero.

Because most people barely know in depth the packaging challenges for one ecosystem. In Python there are maybe a dozen in the world that have a good hang of __all__ of it.

And the devs of this tool would need to know so many.

Of course they don't, they wrap existing tools, which implies exactly what I said above.

show 9 replies
0xbadcafebee12/08/2024

I'm not "a developer" so I never got the use case of tools like these. Instead I just use the stuff they mention (asdf, make).

I use Asdf to manage versions of all programs in a monorepo. Works great (well, actually asdf's UX is terrible, but it works reliably, and the plugin design is great).

For development, I don't ever load environment variables into my current shell session. I run a script or Makefile which loads any necessary variables, does a thing, and then exits. It would be a nightmare to have to constantly check if my current shell session had X variable in it.

I use Make for repeatable small commands that will vary per directory, or for simple parallelizing or ordered execution of commands. I have a big one that handles Helm installs, and a few more for Terraform, Packer, asdf, etc. I also use them for deployments in hierarchical environment directories, where environment variables are loaded from parent directories. I love that Make has all the features it has, because I always find myself eventually reaching for something you don't find in "just a task runner", and it makes my life easier.

I use shell scripts when I need to make a composeable tool that'll be slightly longer or more complicated than a Make target should be. I have saved so much time and effort writing these tools in shell rather than Python or something, where there is inevitably way more bugs and dependencies. The only time I have needed to use something more complex than shell is when I have a lot of APIs to deal with that also deal in JSON; if it's a lot of complexity it's better than curl/jq, but if it's only one small task, curl/jq is better.

The end result works great. The whole environment just needs asdf installed (from Homebrew, for example). With stock Make and the stock Bash v3, I can manage everything automatically, everything's version-pinned and automated, all variables get loaded at runtime as needed, and the whole thing can be grokked by just reading some simple Makefiles.

The only thing I want to fix now is to get rid of the superfluous Makefiles from directories (they're all symlinked back to one Makefile). It's a pain to re-symlink them all when I change directory structure. Probably should just write a script for it...

show 5 replies
DrBenCarson12/08/2024

Just using mise as a drop-in asdf replacement has been delightful

Same functionality but much snappier with better ux

mootoday12/08/2024

I read the project's Readme and all I'm left with is "why?".

I use Devbox[1] and get access to the entire Nix ecosystem, done.

[1] https://github.com/jetify-com/devbox

show 2 replies
Alifatisk12/09/2024

I'm glad people doing frontend are working towards creating a whole toolchain that does everything, like biomejs.dev.

dmarinus12/08/2024

Lately I was thinking "what's the best way to integrate/use a task runner like mise in a github actions workflow".

Looking at the workflow files in the mise repository it seems like they gave up and just put in a few run: mise steps (having to rewrite / unable to use dependencies etc).

I think it would be better if you could generate the workflow files but I haven't found such a project yet.

show 1 reply
ducdetronquito12/08/2024

It's a simple tool that makes my life easier for more than a year: thanks to the creator and contributors :)

lijok12/08/2024

The name is absolutely perfect.

zaptheimpaler12/09/2024

I’ve been using mise at work to manage go versions, it’s been good although a little confusing and undocumented at times. I’ve never used asdf or similar before so there’s probably just a bit of learning curve but this thread is encouraging me to try it more.

langsoul-com12/09/2024

I think if you only use node, then just nvm is fine. This is more for multi language ppl?

show 2 replies
mongol12/08/2024

I use direnv but miss that it can't initialize bash completions as I enter a directory. Can mise do that?

show 3 replies
davidnet12/08/2024

This allowed me to change from pyenv, node and everything into a something really neat and simple, the only thing it caught my surprise was `mise trust` but then the CLI help me to understand, Thanks jdxcode!

show 1 reply
serbrech12/08/2024

As a feedback, having all the examples in that gif on the readme centered around node almost made me look away without a second thought.

sureglymop12/08/2024

This is nice! Jetbrains tools sometimes need a bit more configuration with it, otherwise it's very seamless.

show 3 replies
timfsu12/08/2024

Big fan of mise, moved over from asdf and never looked back! kudos jdx

jindongz12/07/2024

Finally I can retire makefiles in my python projects

show 2 replies
helix27812/08/2024

What is the main difference with just?

show 1 reply
PufPufPuf12/08/2024

Ignoring the task runner stuff, Mise is great just as a "better asdf". It allows many more package sources (including pipx, go and cargo), and it puts the actual executables on PATH -- not shims like asdf, which has a tendency to break stuff.

harha_12/08/2024

All that complexity, for what?

show 1 reply
whydid12/08/2024

Why do JavaScript programmers call ini files "environment variables" ?

show 2 replies
PittleyDunkin12/08/2024

Tbh just having to install node ensures I'll never use this. At least use something like python that's already on my system!

show 5 replies
aiono12/08/2024

This is already a solved problem with Nix shell (except the task runner part). I don't understand why there are any other alternatives still being developed. Nix supports more packages than any other solution, it's battle tested and cross platform (didn't try on Windows but on Mac OS it works fine). And it's more reproducible than any other package manager.

show 7 replies