Le 6 novembre 2024, j'ai publié la note "Le support des variables d'environments de Mise est limité, je continue à utiliser direnv".

L'issue indiquée dans cette note a été cloturée il y a 3 jours : Use mise tools in env template · Issue #1982.

Voici le contenu de changement de la documentation : https://github.com/jdx/mise/pull/3598/files#diff-e8cfa8083d0343d5a04e010a9348083f7b64035c407faa971074c6f0e8d0d940

Ce qui signifie que je vais pouvoir maintenant utiliser terraform installé via Mise dans le fichier .envrc :

[env]
_.source = { value = "./.envrc.sh", tools = true }

[tools]
terraform="1.9.8"

Après avoir installé la dernière version de Mise, j'ai testé cette configuration dans repository suivant : install-and-configure-mise-skeleton.

Le fichier .envrc suivant a fonctionné :

export HELLO_WORLD=foo3
export NOW=$(date)
export TERRAFORM_VERSION=$(terraform --version | head -n1)

Exemple :

$ mise trust
$ echo $TERRAFORM_VERSION
Terraform v1.9.8

Je n'ai pas trouvé de commande Mise pour recharger les variables d'environnement du dossier courant, sans quitter le dossier. Avec direnv, pour effectuer un rechargement je lançais : direnv allow.

À la place, j'ai trouvé la méthode suivante :

$ source .envrc

Je pense pouvoir maintenant remplacer Direnv par Mise 🤞.

J'ai décidé d'utiliser la fonctionnalité "mise env._source" pendant quelques semaines pour me faire une opinion.

-- (from)

J'ai déjà rencontré un problème : il n'est pas possible de lancer des outils installés via Mise dans un script lancé par _.source.

Voici un exemple, j'ai ce fichier .envrc.sh :

export SERVER1_IP=$(terraform output --json | jq -r '.server1_public_ip | .value')

Terraform est installé avec Mise :

[env]
_.source = "./.envrc.sh"

[tools]
terraform="1.9.8"

Quand je lance mise set, j'ai cette erreur :

$ mise set
.envrc.sh: line 6: terraform: command not found

J'ai trouvé une issue pour traiter cette limitation : "Use mise tools in env template".

En attendant que cette issue soit implémentée, j'ai décidé de continuer d'utiliser direnv.

2024-12-19 : suite à la cloture de l'issue indiquée dans cette note, j'ai publié la note Je pense maintenant pouvoir remplacer Direnv par Mise 🤞.

En travaillant sur la note 2024-11-06_1631, j'ai découvert les commandes shell suivantes mises à disposition par direnv que je trouve intéressantes :

• has <command>
• expand_path <rel_path>
• user_rel_path <abs_path>
• env_vars_required <varname>
• on_git_branch <branch_name>

Depuis avril 2019, j'utilise direnv dans pratiquement tous mes projets de développement informatique.

Ce matin je me suis demandé si avec les nouvelles fonctionnalités de gestion des variables d'environnement de Mise, je pouvais simplifier mes development kit 🤔.

Comme vous pouvez le voir dans install-and-configure-direnv-with-mise-skeleton, actuellement mes development kit contiennent deux étapes de modifications de .bash_profile ou .zshrc. Exemple avec Zsh :

• Une étape pour configurer Mise :

$ echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
$ source ~/.zsrhrc

• Seconde étape pour configurer direnv :

$ echo -e "\neval \"\$(direnv hook zsh)\"" >> ~/.zshrc
$ source ~/.zsrhrc

Voici la version simplifiée de ce skeleton basé sur "mise env._source", avec une étape de configuration en moins :

https://github.com/stephane-klein/install-and-configure-mise-skeleton

Voici le contenu du fichier .mise.toml :

[env]
_.source = "./.envrc.sh"

et le contenu de .envrc.sh :

export HELLO_WORLD=foo

J'ai fait le choix de nommer ce fichier .envrc.sh plutôt que .envrc afin d'éviter des problèmes de compatibilité pour les utilisateurs qui ont direnv installé.

J'ai vérifié que les variables d'environnements "parents" sont bien conservées en cas de changement de variable d'environnement par Mise dans un sous dossier.

#JeMeDemande si je vais rencontrer des régressions par rapport à direnv 🤔.

J'ai décidé d'utiliser la fonctionnalité "mise env._source" pendant quelques semaines pour me faire une opinion.

Update : voir 2024-11-06_2109.

Quand je travaille sur le refactoring de ma configuration Neovim, par exemple un passage de packer.nvim à lazy.nvim, je souhaite absolument éviter de perturber mon instance Neovim courante — que je qualifie de stable.
Pour cela, j'ai cherché des solutions pour lancer plusieurs instances de Neovim.

Mon point de départ dans cette quête était trop ambitieux : je souhaitais mettre en place un environemment de travail pour tester la globalité de mes dotfiles basé sur chezmoi.

J'ai explorer les pistes suivantes :

• Travailler dans la session d'un autre utilisateur Unix : je trouve cela vraiment pas pratique.
• J'ai testé une méthode basé sur Distrobox.
• J'ai testé une méthode basé sur Docker.

Finalement, si je me limite à un travail sur ma configuration Neovim, j'ai trouvé la solution suivante minimaliste pour lancer une instance de Neovim cloisonée :

$ export XDG_CONFIG_HOME=$PWD/config/
$ export XDG_DATA_HOME=$PWD/share/
$ nvim

Pour rendre mon quotidien plus agréable, j'exécute ce script ./start_sandboxed_neovim.sh — qui intègre ces instructions.

Je n'utilise pas direnv dans cet environnement de travail parce que je souhaite continuer à pouvoir éditer les fichiers de configuration avec mon instance de Neovim "stable".

En pratique, j'ouvre deux panels tmux verticaux, à gauche j'édite la configuration avec mon instance Neovim stable et à droite je lance l'instance Neovim cloisonée.