idiomatic versions default disabled

[jdx]

I am starting to feel that idiomatic versions should default to disabled and enabled via settings for specific tools. I think back when mise started defaulting to enabled made sense because each language required a plugin. Now that most of the tools with idiomatic versions are core, it's weird that just having a go.mod or Gemfile in the project directory causes mise to install that tool.

While it's certainly convenient that mise works with everything out of the box, I think it's too much and before these files should be used a command like mise settings add idiomatic_version_file_enable_tools ruby.

This is, of course, a breaking change. My plan to roll it out is to show a warning when an idiomatic version file is in use and the setting is not set for 6 months.

I'll leave this open for 30 days and go with whatever people think is best.

[jdx]

my plan:

• add a new setting, idiomatic_version_file_enable_tools = ["ruby"] that does what you'd think (open to ideas on naming)
• deprecate old setting idiomatic_version_file_disable_tools and direct users to new "enable" setting
• if an idiomatic file is in the tree and idiomatic_version_file_enable_tools is not set, show the following deprecation warning:

(example for if .ruby-version was the idiomatic file being used)

deprecated: idiomatic version files like `.ruby-version` are currently automatically
            used by mise but this functionality will be removed in the 2025.9.0 release of mise.
            Explicitly enable idiomatic version file support for ruby with
            `mise settings add idiomatic_version_file_enable_tools ruby` to remove this
            deprecation warning and continue using `.ruby-version` files
            with mise—however note this will cause mise to not read idiomatic version files
            for any other tools unless they are also enabled via settings.

[glasser]

Is .tool-versions considered an idiomatic version in this context?

[jdx]

no

[andrewthauer]

One scenario where having this on by default is helpful would be doing a migration from idiomatic version files to mise.toml files. For example, my org is currently preparing to do migration from using nvm, rbenv, pyenv, jenv, etc. to mise. The fact that mise looks for idiomatic files by default and also merges other tools from mise.toml by default is really useful. It is literally a drop in replacement. We have 100's of repos with these types of files, so having this on by default allows us to support all version managers for a period of time during the migration. We do however intend to migrate to mise.toml files eventually.

Would the idiomatic_version_file setting still work for this change? Or would it be deprecated for the opt in idiomatic_version_file_enable_tools? I suppose we would need to have everyone update the setting during mise setup for this to work. Then eventually disable it. Probably not a huge lift, but it is extra steps.

[jdx]

I think it would probably be something like idiomatic_version_file_enable_tools = ["*"] and we'd get rid of the current boolean since I don't think there would be much use in idiomatic_version_file as an extra method around this

EDIT: I no longer think this is a good idea since it would expose anyone using it to breaking changes when tools are added.

[rubberduck203]

We're in the same boat. We've migrated to mise but decided to use idiomatic version files so that we're not forcing anyone to use mise. Because we've left the idiomatic version files in place, folks are free to use other tools, if they chose to.

I would very much like a way to easily enable idiomatic version files for all tools, with the ability to then disable it for specific tools.

Something like

idiomatic_version_file_enable_tools = ["*"]
idiomatic_version_file_disable_tools = ["python"]

I know you wanted to deprecate the disable_tools settings, so the alternative would be something like

idiomatic_version_file_enable_tools = ["*", "-python"]

Which would feel weird to me, but I could live with.

[jdx]

One thing I'm conscious of is that people might want to do this in specific projects:

[settings]
idiomatic_version_file_enable_tools = ["node"]

to have a mise.toml that effectively dispatches to .node-version. The problem with this is it will override was was set before, like if the user had ["python"] in their global config which is not good.

One solution to this would be to make the tool part of the setting key:

[python]
idiomatic_version_file = true

however there isn't really a way to have fully dynamic settings right now for non-core tools.

[jdx]

I think at least for now I'm going to punt on this

[mockdeep]

I don't fully understand the implications of this. I'm seeing the warning in a project with a .tool-versions file and Gemfile. It seems like in this scenario I shouldn't be seeing a warning, since according to my understanding, .tool-versions is not an idiomatic file. Am I missing something?

[jdx]

hi robert!

Gemfile in this case is the idiomatic file

You can opt-in with mise settings add idiomatic_version_file ruby

[schadenfred]

I am new to mise but would prefer not to have ruby installed just because there's a Gemfile in a directory. This is primarily because I run everything in containers, but even if I was still using rvm I don't think I'd want it.

I am also not in love with having the deprecation show up at all.

[jdx]

I am new to mise but would prefer not to have ruby installed just because there's a Gemfile in a directory

that's exactly what this change is doing. The deprecation message is necessary in order to get users to change their configuration to support the breaking change in 6 months.

[schadenfred]

Sounds good. I do believe this depreciation message is a significant improvement over what I saw:

mise settings set idiomatic_version_file_enable_tools "[]

[ttdatt]

Hi, I want to ask if it's disabled by default, will mise still automatically switch to the Ruby version specified in .ruby-version when I enter the directory, or does it simply not get installed automatically?

[jdx]

it will if you add ruby to the list of idiomatic tools

[jdx]

This poll is closed and was unanimous in favor of making this breaking change when the deprecation message was added. As a general rule, I do not make breaking changes in mise. This is a rare exception for reasons stated above.

If you're new to mise and don't understand any of this, just run mise settings set idiomatic_version_file_enable_tools "[]". That will get rid of the deprecation message and make mise behave as it will once this breaking change is rolled out.

If you rely on idiomatic version files, you'll need to run mise settings add idiomatic_version_file_enable_tools <TOOL> to enable the specific tool you want enabled. In 2025.10.0 the deprecation message will go away and mise will not default to enabling idiomatic version files on all tools as it does today.

[dlibanori]

@jdx doing mise settings set idiomatic_version_file_enable_tools "[]" results in:

[settings]
idiomatic_version_file_enable_tools = ["[]"]

And it think it should be:

[settings]
idiomatic_version_file_enable_tools = []

I haven't found any way to set an value as an empty array other than editing config file directly

[jdx]

that's been fixed in the latest version

[jaredallard]

I think it'd be nice if the warning told you this. As a user of mise who happens to be in some projects that are not using mise, it started getting very mad about that and I had to come here to explicitly say I don't want mise, when I wasn't using mise for this project anyways.

One could argue I shouldn't have mise anywhere in here when I'm using, say, nvm in this project instead (again, not my choice), of course.

[jdx]

I think it'd be nice if the warning told you this

what are you referring to?

[jaredallard]

Sorry -- my version didn't have the commit that told you what commands to run to make the warning go away if you wanted it disabled. I see that was released a bit earlier! (On mobile, so don't have links ready!)

[danielwaltz]

I know I'm a little late to this discussion and I absolutely not only respect the logic around this change but even agree with it!

However, I think the benefit of supporting idiomatic version files when migrating from other tools makes mise adoption smoother by a not insignificant amount. Before this planned change, I could suggest installing mise as a drop-in replacement for other tools without requiring changes in developer's projects, which I see as a big selling point.

Another specific use case for me (and a reason why I plan on setting the idiomatic_version_file_enable_tools = ["*"] option to enable for all tools) is that CI environments and deployment platforms like Cloudflare do not support the mise.toml file natively (at least yet 😉). In these cases, to maintain a single source of truth for versions, I use a .node-version, .bun-version, .deno-version, etc file that both mise and the CI/deployment platform can parse.

Do you think there might be a middle ground here, where plain version files like .[tool]-version are still supported and honored, but more generic files like Gemfile and go.mod are ignored?

[rubberduck203]

@jdx all I’m asking is that you provide a mechanism to easily allow us to make that decision for ourselves.

The likelihood of that becoming a breaking change for me is small, while the change you’re making is a breaking change I have to deal with. I’m asking you to make it a little easier to preserve existing behavior.

[jdx]

You don't speak for everyone that may use this feature and won't be aware they'd be exposing themselves to breaking changes. I'm also no fan of "we don't have breaking changes in mise except when using this one specific feature".

[rubberduck203]

@jdx I’m not trying to speak for everyone, but the reactions to this comment of mine suggests to me I’m not entirely off base by asking for an easy way to preserve existing behavior, understanding the consequences of me making that decision.

#4345 (reply in thread)

[ttdatt]

I voted yes, but I now regret that decision. I ended up adding ruby, python, node to the list of idiomatic tools hahaha I assumed that mise would at least tell me to the discrepancy between the default tool version in mise config and the one specified in .python-version, but it didn't, ended up wasting my time trying to fix the project's build error.

[jdx]

the warning does show the idiomatic tool that is missing and describes how to add it, however that will go away in a few months once this changes to be default behavior. At that time there won't be a warning on which we could display anything.

I'd probably accept a PR to show it on mise cfg or mise ls if someone finds a decent way to do it—likely behind a flag since you wouldn't want the default behavior of either command showing tools/configs that mise isn't using. For that reason I don't see a ton of value since I doubt people would discover this flag very easily but I see enough value to accept a PR.

[duelinmarkers]

As a brand new mise user, not knowing to use ruby for the <TOOL> mentioned in the below message was a speedbump, leading to a web search and this thread. It would be sweet if it gave the verbatim command needed for the tool whose idiomatic version file triggered the warning.

mise WARN deprecated [idiomatic_version_file_enable_tools]: idiomatic version files like ~/src/web/Gemfile are currently enabled by default however this will change in mise 2025.10.0 to instead default to disabled.
You can remove this warning by explicitly enabling idiomatic version files for with mise settings add idiomatic_version_file_enable_tools <TOOL>.
See #4345 for more information.

[jdx]

it always did this but there was a bug specific to Gemfile. It should be fixed now and always display the tool.

[schadenfred]

I had the same experience. The verbatim command would have solved the problem for me.

…

On Wed, Apr 23, 2025 at 2:25 PM John Hume ***@***.***> wrote: As a brand new mise user, not knowing to use ruby for the <TOOL> mentioned in the below message was a speedbump, leading to a web search and this thread. It would be sweet if it gave the verbatim command needed for the tool whose idiomatic version file triggered the warning. mise WARN deprecated [idiomatic_version_file_enable_tools]: idiomatic version files like ~/src/web/Gemfile are currently enabled by default however this will change in mise 2025.10.0 to instead default to disabled. You can remove this warning by explicitly enabling idiomatic version files for with mise settings add idiomatic_version_file_enable_tools <TOOL>. See #4345 <#4345> for more information. — Reply to this email directly, view it on GitHub <#4345 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACC5COQWD2C4WI4KKJXRL23AALNAVCNFSM6AAAAABWXVUXSSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEOJSG43TOMY> . You are receiving this because you commented.Message ID: ***@***.***>

[jvortmann]

Should the deprecation message be shown even when the setting is configured?
I've ran the mise settings set idiomatic_version_file_enable_tools ruby and it still showing the message due to the Gemfile.
I would expect it to be gone after the setting is on.

Also, it is probably a good ideia to have all available tools that can be set there in the docs. That way we can retro-fit project to use specific tools before getting the deprecation message or after it is gone.

[risu729]

For the deprecation message, I could not reproduce it in my environment.

[jvortmann]

These are my settings:

When I list them, the array is empty:

So every time I run something like rails db:migrate (or any other ruby / rails command), I got this warning:

[risu729]

I can see that idiomatic_version_file_disable_tools is empty, but what about idiomatic_version_file_enable_tools?

Could you copy and paste the output of mise doctor?

[janeklb]

it's weird that just having a go.mod or Gemfile in the project directory causes mise to install that tool.

@jdx is this the main / sole reason for this change? It makes me wonder if you are thinking of dropping support for idiomatic version files in the future.

Also, related but a bit tangential, is there some other setting that would "cause mise to install that tool", or are you simply referring to the behaviour resulting from running mise install?

[rubberduck203]

I think the default behavior is to auto install, but I’d have to look at the docs.

[jdx]

I think you misunderstood that point, I'm just saying it's weird that mise manages tools that were never explicitly configured to be managed by mise. It's not about installing per se

[janeklb]

Got it.

Well, for what it's worth, it's certainly not weird to me. In fact, IMO it's a huge selling point of mise.. as others have put it - it can serve as a drop in replacement (for other tool version managers) with little to no configuration needed.

[janeklb]

@rubberduck203 what do you mean by auto install? From my experience, changing into a dir with a mise.toml file will only activate tools if they're available (but not install them). That said, I don't know what the not_found_auto_install setting does.

[jschear]

Just wanted to applaud this decision -- I work at a company where some repos have adopted mise and others are using their own tooling, and it was quite confusing that cding into a project not intentionally managed by mise would muck with their environment. 👏

[glasser]

Yes. I'm sympathetic to the old/current behavior for solo use of Mise, but we also just started adopting Mise at my company and I forgot that instead of it being a repo-by-repo thing as we add Mise files, it would suddenly start affecting other repos that use other mechanisms. (People like mise and are happy to, say, replace Volta and nvm with Mise, but it was surprising that this just started happening automatically.)

[rubberduck203]

We found no reason for “some repos to use mise” or for it to be a “repo-by-repo” thing FWIW. At least, not with the current/deprecated behavior. That was a common misconception for us at first, but the reality is, you just remove rbenv, nvm, and friends, install mise and it just worked everywhere.

We’re now in the process of distributing an /etc/mise/config.toml to everyone to enable idiomatic version files.

[glasser]

I agree, but we don't do it all in one atomic change across every project at our company! People are enjoying the improvements of Mise and now we're going to spread it elsewhere, but you gotta earn trust around new tools...

[jdx]

I've always felt it was important for mise functionality to be opted into in pieces. For example, a team may want to use mise simply for task management and not tool management and that's very much a supported use-case. Teams often find that mise makes sense for some tools but not others.

[glasser]

Also worth noting that if we want to allow people to use either mise or the native tool (eg nvm) in a repo, we can just check in

[settings]
idiomatic_version_file_enable_tools = ["node"]

to a mise file in the repo, which works nice.

[jdx]

One thought I had around this was perhaps we could configure based on filename instead of tool name, e.g.: mise settings add idiomatic_version_filenames .node-version

It'd be quite a bit more challenging to implement but I think it's possible. It'd be easier once the old logic is sunset. One issue with this approach might be if 2 different tools had the same filename—though I don't think any standard setup would have this.

[jdx]

Also at least in my company and team, it's rare to have everyone rally around a single tool unless absolutely required. The value of a generic file that many tools support means that folks can more easily choose the tool they are most comfortable with without forcing a specific tool on them.

this is the reason for disabling it by default—otherwise anyone that has mise installed would be forced to use it unless they go out of their way to disable it for specific tools. Just because someone has mise setup doesn't mean they want to use it everywhere or even at all.

[danielwaltz]

Hmm... how does auto install even work currently then? When I use mise, I don't expect a tool to be installed unless I manually run mise install in a project directory. Is there a configuration now that automatically runs mise install when entering a directory? Or is the issue mostly in mixed mise + other tools projects where you may want to use mise for some tool versions, but a separate version manager for others? Rust probably the most likely culprit here as I don't know any rust developers who don't just use rustup for that.

Sorry for all the questions, just trying to understand things more completely so I can talk about this change with others with more accuracy. I shared the awesomeness of mise with a handful of other developers at my company as a tech lead and want to be prepared.

[vraravam]

Well put @danielwaltz ! That's exactly my sentiment as well.

[janeklb]

+1 to the question about auto install. I've toggled the not_found_auto_install setting a few times but haven't seen any difference in the behaviour. I'm not sure what "auto install" process that setting is referring to.

Aha. I found #3379 (comment) which in turn lead me to uninstall a tool and then trying to invoke it directly (after it was uninstalled).

eg

• mise uninstall terraform@1.11.4 which uninstalls the terraform tool
• terraform --version which should print the terraform version; however since it's not installed/found, mise will automatically download it (if not_found_auto_install is set to true)

[jdx]

I think there is some confusion here, likely on my part but I'm not sure where I may have misspoke. To me this issue has nothing to do with not_found_auto_install since that only operates on tools that are already managed by mise somewhere else. I don't think it would be a huge deal if mise started managing an existing tool.

To me the issue is more that running mise install with no args will glob up any .ruby-version or .go-version in the project even if you never wanted mise to manage that tool.

[AjaiKN]

Maybe mise could produce a warning by default when all of the following conditions are true:

1. The tool (e.g., Ruby) is currently being managed by mise. This might be because there's a mise.toml file in the current/parent directory (e.g., if mise.toml has the line ruby = 3.3.0), or it might be because the user has a global default enabled for the tool (e.g., if ~/.config/mise/config.toml has the line ruby = 3.3.0).
2. There's an idiomatic version file in the current directory that's being ignored by mise (e.g., 3.1.0 in .ruby-version).
3. The version that mise is using (3.3.0 in this example) is different from the version specified in the idiomatic file (3.1.0 in this example).

Because it would just be a warning, this wouldn't be a breaking change when new idiomatic version files are introduced. It also wouldn't be very intrusive, since the warning would only appear if mise is currently managing the tool in question and there's a mismatch between the version chosen by mise and the idiomatic version file.

[jdx]

warnings are way too noisy for this to work

[pikeas]

It seems like version files are being conflated with project files.

Gemfile present: new default makes sense, don't install Ruby unless asked.
.ruby-version present: if I understand correctly, the presence of this file will no longer trigger tool installation. IMO, this doesn't make sense; the presence of this file expresses the user's intent to have Ruby installed.

[jdx]

it certainly does not express their intent to have ruby installed with mise

[pikeas]

I disagree - a .python-version or other version file expresses the intent that "anything that manages versions of this thing, should ensure this specific version of it". It's tool agnostic.

[vraravam]

I agree with @pikeas - that's the way I (as a user of mise) would expect.

From what I understand, the whole point of mise (or asdf or rtx....) was to have a single tool that manages multiple versions of multiple languages. At least in my opinion, having only certain folders/tools/versions being managed by mise on the same computer while also having other tools manage other configs seems to contradict/defeat that "universality" aspect.

I would hope that this breaking change is done opt-in (for those folks who want such a multi-tool setup) while the rest of us who have been using mise can continue without needing to forcefully adopt such a breaking change.

[jdx]

You've conflated the idea that mise can manage tools with the idea that it should manage them. From the beginning I've designed mise such that you don't have to use mise for anything. This behavior went against that design goal—in fact I considered labeling this behavior a "bug" since it certainly was not intentional.

I'm not saying you have to like or agree with this functionality but you can't say that it goes against the "point" of mise—that's not a matter of opinion. This change was made precisely because the existing behavior was so misaligned with my design goals that I felt it was worth a rare breaking change to get the project back into alignment with what mise should be.

If what you want is a tool manager that snarfs up any generic version file it finds mise is not it, has never (intentionally) been it, and will never be it. To be clear, that doesn't mean I don't think generic version files are useful or are going anywhere. I have a big problem with them being used by default.

I would hope that this breaking change is done opt-in (for those folks who want such a multi-tool setup) while the rest of us who have been using mise can continue without needing to forcefully adopt such a breaking change.

To be clear, this breaking change is happening because the behavior is misaligned with the project goals. There's no such thing as an "opt-in breaking change"—that would just be things staying the same. If you want the existing behavior you set idiomatic_version_file_enable_tools.

[StingRayZA]

Any way to suppress this message on every new terminal?

mise WARN  unknown field in ~/.config/mise/config.toml: settings.idiomatic_version_file_enable_tools
mise WARN  unknown field in ~/.config/mise/config.toml: settings.idiomatic_version_file_enable_tools
mise WARN  unknown field in ~/.config/mise/config.toml: settings.idiomatic_version_file_enable_tools

~
❯ cat ~/.config/mise/config.toml
[settings]
idiomatic_version_file_enable_tools = []

❯ mise version
              _                                        __
   ____ ___  (_)_______        ___  ____        ____  / /___ _________
  / __ `__ \/ / ___/ _ \______/ _ \/ __ \______/ __ \/ / __ `/ ___/ _ \
 / / / / / / (__  )  __/_____/  __/ / / /_____/ /_/ / / /_/ / /__/  __/
/_/ /_/ /_/_/____/\___/      \___/_/ /_/     / .___/_/\__,_/\___/\___/
                                            /_/                 by @jdx
2025.5.3 macos-arm64 (2025-05-09)

[glasser]

Is it possible you accidentally have two versions of mise installed or something, and the one being run in your new terminal is the old one?

[jdx]

@glasser is correct