Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
 help



Why would you even use python without uv anymore, and have a system python binary and virtual envs linked to it?

> Why would you even use python without uv anymore

Probably wouldn't:

https://mise.jdx.dev/mise-cookbook/python.html#mise-uv

> have a system python binary and virtual envs linked to it

I'm not sure if you're saying avoid using system python?

In my experience so far, you never want to develop complex software locked to system versions of runtimes. Too often you need a bleeding edge feature, or conversely need to postpone updating due to needing an old version for some reason.


Old Mise user too.

Now that PNPM supports managing runtimes [0], I found that most of Mise's offerings are actually built into package managers. Maybe I will have it graduates from my machine when I have time.

[0]: https://pnpm.io/cli/runtime


That's the beauty of asdf and then mise; they leverage existing solutions where possible, and unify how to get versioned runtimes for projects. Rust? rustup with mise, ruby? Precompiled when possible, otherwise ruby-build. Etc.

I'm not sure if I trust or want pnpm to support bundling rust for binary plugins, or various sundry toolchains.

But use what works for you.


> I'm not sure if you're saying avoid using system python?

That's what I'm saying, yes. System python should be treated as a REPL for interactive shell scripting and otherwise ignored entirely.


Python might be just one of the languages required by the dev stack not the only language. Mise is the right tool for the job.

True, but Python is the one with an env management system (virtual environments) which is the most prone to breakage for projects that depend on system Python.

Uv is far superior to both Mise and Homebrew for Python work, and I find that it removes the vast majority of pain preventing me from using Homebrew by default for most things, and Mise only occasionally for specific dev envs. Mise is a great tool though!


Last time I checked, Mise is still a one-man show. That’s way too risky for a critical party of my supply chain for my taste.

this makes no sense to me, the reason i don't give anyone else the commit bit is only to _protect_ the supply chain. you should want as few people with that access as possible.

I think the concern is more if something happens to you or stop development for any reason, then the project is dead or would fork in a few separate directions

The bus factor makes no sense to you?

https://en.wikipedia.org/wiki/Bus_factor


do you have any kind of succession plan in place in case you get incapacitated for one reason or another? anyone you trust enough for that?

Yes I have a friend that can access my GitHub if I were to die and he would be in charge of deciding who would lead the project

So is sudo... And that's not "too risky" for the entire industry.

That's not to say bus factor is irrelevant (I personally think about it a lot when choosing software projects), but truthfully the bus factor here especially doesn't matter much, as mise is an easy tool to replace (with asdf, for example) if something goes wrong with it eventually.

I highly recommend trying it out. I resisted using it for some time, but it solved some pain points I had with NodeJS, Ruby, and Python regarding installation.


> So is sudo... And that's not "too risky" for the entire industry.

Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package. That's different for Mise, though, because there are a lot of ways to work productively without it. I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.


   > Sure it is, and that's why I'm looking forward to systemd's Run0 -- but for now, there's just no way around the sudo package.
Regarding Run0, I'd prefer to not rely so much on Polkit authentication after crazy vulnerabilities such as PwnKit (a pkexec vuln, but a good reminder that moving the security boundary won't magically solve issues).

   > I'm not fond of consciously adding supply chain vulnerabilities to our stack when I don't have real pain to do so.
I SUPER agree with you on that, btw. It's just likely that mise solves a problem which is much bigger for me than it is for you. Honestly, I'd prefer if I could manage everything with my distro packages, but, for a multitude of reasons, they're rarely enough for development tooling with multiple versions and environments.

I split my usage. Homebrew for OS things mise for the various tooling.

The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.


You can use mise for install homebrew items btw so if you get a new computer you just drop the config.toml inside the mise and install.

This is all you have to add to the config file:

[bootstrap.packages]

"brew:git" = "latest"

"brew-cask:ghostty" = "latest"


Homebrew does this as well, I keep my packages synced with a Brewfile in chezmoi. Obv this only works for brewed packages though.

I've found `mise` more useful solely because it also handles things like tasks and daemons.

Yeah, the combination with mise is what make this great.

I also started using Mise for global CLI tools instead of brew and it’s working really well

Eg: mise use -g gcloud instead of brew install xxx

It can even do that for npm packages! Like mise use -g npm:xxx


re: npm, if you upgrade your global node version, you will lose that installation, right?

no, in fact you don’t even need node or npm to install npm packages with mise. (You likely will need it to execute them though)

Mise is really sloppily vibe coded these days

What broke and affected you?

my split: brew for casks, mise for tools

mise also can manage brew

Okay



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: