Make MISE_ENV a setting

[davidolrik]

I want to be able to set MISE_ENV when entering a project directory.

To do this today I need to export MISE_ENV every time I create a new shell.
Setting it in my shells profile is not an option for me, as I might have different MISE_ENVs for dirrerent projects at the same time.

If MISE_ENV was a settnig them I could set it in my main mise.toml in each project and it would just work™

If MISE_ENV is set in the environment then this should tage precedence over the config value.

[glasser]

Yeah, I'd like this too — for example, we can have a shared project that has a few different mise.mac-dev.toml, mise.linux-dev.toml, mise.ci.toml files checked in, and tell developers to set their environment to mac-dev in a mise.local.toml to engage it.

[glasser]

I suppose one could get something like what I want by just putting the files in question in a totally different filename and having people add local symlinks from ignored files, or something like that.

[nahco314]

I’m also interested in this. On mise running under the Fish shell, it sort of works, but shows some odd behavior:

$ cat ./mise.toml
# empty

$ cat ./mise.local.toml
[env]
MISE_ENV = "aaa"

$ cat ./mise.aaa.toml
[env]
AAA_ENV = "OK"

$ echo $MISE_ENV, $AAA_ENV
aaa,

$ touch ./mise.toml

$ echo $MISE_ENV, $AAA_ENV
aaa, OK

When I did a quick test with Bash, it seemed to work fine, so I’m not really sure. It might behave differently depending on the shell.

[davidolrik]

You can't put MISE_ENV in [env] - it needs to be handled before the mise toml files are loaded.

Today you can to mise -E <my-env>, but you have to remember to do it each time, or you can manually set MISE_ENV in your environment before invoking mise.

[betaboon]

i was hoping [settings] env in a mise.local.toml would work, but that's also not the case :(

[jdx]

just to set expectations: I think this is a bad idea. By "bad" I don't mean that I don't see the value (I certainly do), but that I don't think it's realistic. I doubt I will ever look into supporting it and I would advise against even trying to figure out how this could work. Even if we had such functionality I would caution against using it because it would certainly result in strange behavior and bugs even in the best of situations.

To understand why, you need to think about how mise works. mise first does a pass to figure out which config files it will load, then it loads all of them in parallel. What you're asking for is a way to have something in a file have some way of modifying which files would have been loaded which is a paradox.

I'm sure people won't like my response here but really I think you're asking for something that just isn't realistic. It's not that I don't see the value in having this, it's that I have no idea how any solution could possibly work—at least not without glaring edge-cases or complex documentation prescribing how it would need to be used. You're welcome to try to prove me wrong of course, I'm willing to be persuaded. I don't think it's likely a good use of your time though.

Settings could in theory do this because the config files actually get loaded twice, once for settings and once for config files. However this would mean the config files used for settings would be different than those used for config files. While technically that would solve some of these use cases it's bizarre behavior that would need to be clearly documented and on those grounds alone I would prefer to just keep things simpler and not do it at all.

Yes there are ways this could be solved by doing things like having multiple passes of loading config files or having things run in series but in those cases you'll have complications related to the order things are parsed. It's going to be very complicated. I do not think it's worth it. The example above of using mise.local.toml to load files like mise.production.toml is a perfect example. Even if we loaded things in series you would almost certainly need to use mise.production.local.toml because of the load order. And even then, what if you wanted a mise.local.toml to load a global ~/.config/mise/production.toml? What if you have conflicting envs? I think it's possible for mise to work this way—however it'd be extremely hard to build and explain the caveats. I'm not touching it for sure.

My guidance is that you should not try to use mise to configure the way mise loads config files inside of config files. I hope you can see from that sentence alone why it doesn't make sense. Taken strictly, what if a config file said that it should load itself? Or not itself? This means don't try to use it for settings like override_config_filenames. You should always use env vars for those outside of mise. In some cases these things may work but that's likely just accidental. I would not rely on them and would prefer we try to deprecate anything around config file selection from being able to be modified inside config files.

I've recently started adding documentation to the settings around these clarifying which configuration only works as an env var. If you see that, it's likely not because mise needs to do more work to support using them as a setting, it's because using an env var is the only way that particular setting actually makes sense with the way mise works under the hood.

I would prefer not to discuss this anymore but I suspect people will come to me with ideas. In my experience this usually results in ideas that solve one part of the solution but not another. I'll read whatever people write here but unless you present a full solution that truly does capture all the problems—or at least close enough to that—I likely won't engage with this anymore.

[jdx]

there was some discussion in chat that gave me an idea on how this could be solved. It might be possible to add a plugin touch point similar to https://mise.jdx.dev/environments/#plugin-provided-env-directives but for config load paths. It would take in a list of config files mise wants to load and return a list of config paths added/removed which mise would then load.

That way mise itself wouldn't need to be concerned about this problem and I wouldn't need to handle all the edge cases. People could write plugins to have behavior they want. The problem for me putting this into mise is I don't see a way to write it that would ultimately make everyone happy but if people have the option of using plugins they can use particular plugins that gets the behavior they want.

I'm not 100% sure it would work though. I did glance through the code and I don't see plugins relying on a full Config to be initialized before they can execute. So long as that is true we would be able to add a touch point here.

I'm not going to do it, this isn't something I have any interest in solving but I would accept a PR for that and assuming there aren't any hidden issues with the initialization order I don't think it would be challenging to build. It would need to be limited to vfox plugins only for performance reasons (you don't want mise shelling out to bash every time it runs an asdf plugin).

[betaboon]

(original message on discord, copying it here for the papertrail):

@jdx I've been poking around a little regarding the config_paths mise-plugin idea we talked about a couple of days ago.
I'd assume the call to that plugin-touchpoint would go here: https://github.com/jdx/mise/blob/main/src/config/mod.rs#L105-L108

i noticed a few things, that put questionmarks over my head, maybe you have some thoughts you'd like to share:

plugins that make use of MiseEnv and MisePath seem to only be loaded here: https://github.com/jdx/mise/blob/main/src/config/env_directive/module.rs#L10
which, if i understand this correctly, happens way later.

i assume we're talking about something along the lines of function PLUGIN:MiseConfigPaths(ctx).
if that's correct, it had to be implemented as a new hook in vfox.rs like https://github.com/jdx/vfox.rs/blob/main/src/hooks/mise_path.rs

i assume MiseConfigPaths would have to be provided all config-files that could be loaded (including env-specific files, regardless of whether that env is selected), while load_config_paths currently returns the config-files that will be loaded.

[jdx]

I think you've broadly got what needs to happen. It's definitely possible we may need to refactor the loading logic in order to get it to work properly.

[jschnare]

Has a local file like .mise/default_env already been considered? I'm thinking something like this logic:

if [ -z "${MISE_ENV+x}" ]]; then
  if [ -r .mise/default_env ]; then
    export MISE_ENV=$(<.mise/default_env)
  fi
fi

It could possibly go in the mise activate shell logic, but then we'd have check if we're in a mise-controlled directory. But perhaps it could be done before building the list of config files.

[jdx]

I think a .miserc file could fill this gap

[bas-de-laine]

Which would be a different process than mise? My understanding is that MISE_ENV should never be set during mise computation of the current environment. Said otherwise, MISE_ENV must be set outside of mise purview.

My current strategy is to use a zsh precmd hook that is registered before mise's hook. A MISE_X_ENV_FILE env var points to a relative path to where a file contains what to set MISE_ENV to. I use .mise/.mise_env.

So, the precmd hook checks whether a $MISE_X_ENV_FILE exists and if so, loads its content and exports MISE_ENV.

It works.

I use a mise hook like [hooks].{cd,enter} and even [env]._.source script to compute MISE_ENV and generate the $MISE_ENV_FILE content.

So, mise computes the value of MISE_ENV, but an external system exports the value.

[davidolrik]

A .miserc would simply be loaded by mise during startup, any settings would be merged with command line args and the env in the correct order, and then mise would do the loading of toml files.