Consider adding `-l`/`--local` flags and/or syncing command flags

[rliebz]

Much like How I use mise from the docs, I've been taking advantage of .mise.local.toml. Ideally, I'd like to manage this by CLI as much as possible, but there are a few rough spots for me in the workflow—

• I've been typing mise use -e local a lot, generally for projects where the maintainer wouldn't want. This one is pretty fine on its own.
• I generally check my various tool settings files into git for use across multiple machines, but I personally consider the list of applications and their installed versions to be more a property of the machine's state rather than configuration, if that distinction makes sense. I considered checking in ~/.config/mise/config.toml with settings and using ~/.config/mise/config.local.toml for managing tool versions, but I struggled to make this work through the CLI. The first thing I tried was mise use -g -e local, but it looks like the -e flag overrides both -g and -p (if a directory is specified). It seems like I could do this by CLI with -p ~/.config/mise/config.local.toml, which works (even though it's a bit verbose). For now I haven't been checking my config into VCS at all, which isn't a huge deal, because there's only 2 things I've been setting.
• For setting env vars, I type mise set -f .mise.local.toml. A little more verbose, again probably okay in isolation, but It takes some getting used to that the config path options for use and env differ.
• I haven't really had a need for mise settings with any file other than the default global config file, but I was surprised to see (a) that there was no way to do this by CLI, and (b) that = signs were disallowed

The grand sum of those use cases is that I would write to .local.toml files by CLI using 3 different syntaxes of varying verbosity, depending on the command:

• mise use -e local foo@1.2.3
• mise use -p ~/.config/mise/config.local.toml foo@1.2.3
• mise set -f .mise.local.toml foo=val
• Settings in ~/.config/mise/config.local.toml cannot be changed via CLI

Ideally what I would like to be able to do is this:

• mise use -l foo@1.2.3
• mise use -gl foo@1.2.3
• mise set -l foo=val
• mise settings set -l foo=val (with rules on = consistent with mise set)

Alternatively or additionally, making the syntax consistent between all commands without defining any new flags would go a long way:

• mise use -e local foo@1.2.3 (currently implemented)
• mise use -g -e local foo@1.2.3
• mise set -e local foo=val
• mise settings set -e local foo=val

[jdx]

I think a local flag makes sense. Maybe also --env could be used without an argument to leverage MISE_ENV to find the current one though I dislike optional parameters on args

[rliebz]

Yeah I'm not sure there's a great way to make a flag have an optional argument without requiring = (e.g., --boolean=false vs --boolean), and if --env already exists it's probably too late for that.

You could always add a separate flag like --auto-env, although I'm not sure I'd personally take advantage of an automatic env discovery flag either way.

[BasixKOR]

Adding my use-case here: I work on a repository where I'm not able to decide on what tools it will use, but I still bring my tools regardless. An example: the checked-in .mise.toml specifies node@20 but I may use bun in my mise.local.toml. This also applies to my dotfiles so I have a similar use-case for global local tools too.

For me adding -l makes sense. I don't feel like local is an environment; it's an exception from the usual environment definition (or the undefined state). Would you mind if I work on adding -l flag to both mise use and mise set?

[jdx]

An example: the checked-in .mise.toml specifies node@20 but I may use bun in my mise.local.toml.

is the issue that bun and node are both installed? I don't see why that would be an issue except the first time you unnecessarily install node.

[jdx]

my biggest issue with adding --local is that it has different meaning than mise settings --local which means not-global. We don't use --local to specifically refer to mise.local.toml anywhere.

I also think this is less important now that mise use defaults to mise.local.toml if it is defined.

[rliebz]

my biggest issue with adding --local is that it has different meaning than mise settings --local which means not-global.

Yeah I think it gets tricky with that flag existing. The challenge I have from an understanding perspective is, presumably the "global" config file is ~/.config/mise/config.toml. And then the "local" config file would be ./mise.toml. But then what would ./mise.local.toml be called?

We don't use --local to specifically refer to mise.local.toml anywhere.

It's a little awkward because the word "local" is explicitly used in the context of the file name, even if it's not used in the CLI. But I'm less concerned about the name of the flag compared to the flag existing, if there's another word that you'd prefer to use. I'm bad at naming so I'm not sure I have one. There's also the option of renaming the existing --local flag, especially since I believe it's relatively new, but obviously I appreciate that supporting this particular use case isn't the only priority to consider.

I also think this is less important now that mise use defaults to mise.local.toml if it is defined.

The challenge for me is that I'm often working across a number of projects and folders at any given time, and I generally have no idea if I've set up a mise.local.toml file yet or not. So what I would struggle with is how I'm meant to set the very first value so that it ends up in mise.local.toml, but also to be able to configure that without having to check the file system for the existence of mise configuration files to be able to predict where things are going to land. Having a short flag seems like the most straightforward way to accomplish that, but figured I'd share the use case because it's maybe not the only way.

[jdx]

I might be wrong but I think if you set MISE_ENV=local it will default to writing mise.local.toml. If not, it probably should do that.

I'd be open to using something else to refer to "not global" other than "local" but I don't know what it would be. I considered "project" but I feel like users would expect mise settings --project to need a value of some kind.

[jdx]

the way I think of it is mise.local.toml refers to the local environment not being a local config file

[rliebz]

I like --project, and wouldn't expect it to require a value, especially if the CLI documentation was there. Alternatively, something along the lines of --working-directory/--workspace might make sense.