More features for Environments?

[jdx]

I'm wondering what more could be done with the environments portion of rtx.

Now that I'm presenting rtx less as a direct clone of asdf and a suite of tools, envs, and tasks, I feel the "env" section is a little light. Any thoughts on what else it could do?

Lack of features certainly isn't a problem of course, but I'm wondering if there's some potential we might be able to take advantage of.

I am considering moving the virtualenv stuff from python over to it for one, but that's not new functionality.

A couple of ideas:

• activating a nix shell
• external command for dynamic env vars
• something with gitconfig or other git-related?

[davidolrik]

I would so love this! - I was just about to start a new discussion about what I need to get rid of direnv completely.

In direnv I have a lot of little "plugins" or helper scripts if you will, just like use_mise that is provided by mise, that modifies my shell environment according to "environment" and "context".

I work for multiple clients, and I assign a named environment to a specific iTerm window using a helper: set_named_environment client_x.
I also have a "context" which is set dynamically according to my location and this gives me lots of options to change my actual environment accordingly. (direnv has a watch_file command that I use to trigger a context change, but only when this one file changes.)

Here is some of my helpers:

• use_privoxy - Sets all proxy environment variables needed for using Privoxy
• use_proxyman - Sets all proxy environment variables needed for using Privoxy
• fix_gitconfig - Takes GIT_AUTHOR_* and GIT_COMMITTER_* and adds it to the git config (for apps that don't have access to my environment)
• set_project_dir - sets $p to a specific directory based upon my current "context" and "environment"
• set_named_environment - Associate a name with a iTerm window
• iterm2_window_title - Change the iTerm window title and badge

All of this is done from within .envrc, so a similar mechanism in mise would be much welcome.

[jdx]

these are great, if you don't mind sharing them I'd love to take a peek to see how they work. Do you think this might be as simple as just being able to run an external command to fetch env vars and have a similar mechanism to watch_file?

If so, this actually won't be that hard to do. Internally mise already makes use of something like watch_file. It would be trivial to expose it if you wanted to add to it. Templates are already capable of setting individual vars, e.g.:

[env]
GIT_AUTHOR = "{{ exec('foo') }}"

(not 100% on the syntax but something like that)

noodling on this, we could do something like this:

[env]
mise.exec = '~/scripts/git_author.sh'

[watch]
files = ['~/scripts/git_author.sh']

that said, I already add env_file's to the watch list, so I'd probably just do the same with exec scripts. You would only need to set watch.files if you wanted to add additional configuration.

[jdx]

one problem we may run into is exacerbating #1261, but I think that could be addressed

[noirbizarre]

Following #1357 (comment), I share my concern about making env a one-catch-all section.

One thing I like with mise over direnv: the structured file format, toml lower the need for scripting while make edition a bit more easier.
If mise start going this way, env will, in my humble opinion:

• loose its semantic
• be harder to parse or validate
• be harder to read
• be more and more cluttered while plugins add extras settings into it
• loose the benefit of a structured file format

I like the current separation of concerns where env only purpose is to declare environment variables.
Following this principle, I would advocate for plugin dedicated section for fine tuning.

However I would have 2 env sections, one executed before tools activation, one after to be able to reference side effects of activations.
This would allow this kind of .mise.toml:

[env]
SOME_VAR_THAT_MIGHT_BE_NEEDED_BEFORE_ACTIVATION = "value"

[tool]
python = "3.11"

[python]
virtualenv = ".venv"

[lazyenv]  # just for the example, naming TBD
SOME_VAR = "{{ env.VIRTUAL_ENV }}/some/extra/path"

Combinated with #1262, this would give a lot of possibilities while keeping toml strictness.