jdx / mise

dev tools, env vars, task runner
https://mise.jdx.dev
MIT License
9.12k stars 247 forks source link

mise resets in original terminal after opening another terminal #2384

Open winstontsai opened 2 months ago

winstontsai commented 2 months ago

Describe the bug I have an open terminal window with a Python virtual environment active. Opening a second terminal window causes mise to "reset" in the original terminal, putting the mise paths in front of the venv paths.

To Reproduce

I'm using bash on macOS.

  1. Open a terminal window and activate a Python virtual environment. Run type python a few times to verify the Python venv is activated.
  2. Open another terminal window.
  3. Go back to the original terminal run type python once. It still shows the venv is activated. But run type python again, and it shows mise python. Checking $PATH reveals that mise paths are in front again.

Expected behavior Opening a second terminal should not affect the environment of the first terminal.

mise doctor output

version: 2024.7.3 macos-x64 (2024-07-14)
activated: yes
shims_on_path: no

build_info:
  Target: x86_64-apple-darwin
  Features: DEFAULT, NATIVE_TLS
  Built: Sun, 14 Jul 2024 03:08:35 +0000
  Rust Version: rustc 1.79.0 (129f3b996 2024-06-10) (Homebrew)
  Profile: release

shell:
  /usr/local/bin/bash
  GNU bash, version 5.2.26(1)-release (x86_64-apple-darwin22.6.0)
  Copyright (C) 2022 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

  This is free software; you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.

dirs:
  data: ~/.local/share/mise
  config: ~/.config/mise
  cache: ~/Library/Caches/mise
  state: ~/.local/state/mise
  shims: ~/.local/share/mise/shims

config_files:
  ~/.config/mise/config.toml

backends:
  cargo
  core
  go
  npm
  pipx
  spm
  ubi

plugins:
  bun     (core)
  deno    (core)
  erlang  (core)
  go      (core)
  java    (core)
  node    (core)
  python  (core)
  ruby    (core)
  usage   https://github.com/jdx/mise-usage.git#fe3888a

toolset:
  node@20.12.2          
  java@corretto-17.0.10.7.1  
  python@3.12.4        
  usage@0.1.18          

env_vars:
  MISE_SHELL=bash

settings:
  activate_aggressive = false
  all_compile = false
  always_keep_download = false
  always_keep_install = false
  asdf_compat = false
  cargo_binstall = true
  color = true
  disable_default_shorthands = false
  disable_tools = []
  experimental = false
  go_default_packages_file = "~/.default-go-packages"
  go_download_mirror = "https://dl.google.com/go"
  go_repo = "https://github.com/golang/go"
  go_set_gopath = false
  go_set_goroot = true
  go_skip_checksum = false
  http_timeout = 30
  jobs = 4
  legacy_version_file = true
  legacy_version_file_disable_tools = []
  node_compile = false
  not_found_auto_install = true
  paranoid = false
  plugin_autoupdate_last_check_duration = "7d"
  python_default_packages_file = "/Users/winstontsai/.default-python-packages"
  python_pyenv_repo = "https://github.com/pyenv/pyenv.git"
  raw = false
  trusted_config_paths = []
  quiet = false
  verbose = false
  yes = false
  ci = false
  debug = false
  trace = false
  log_level = "info"
  python_venv_auto_create = false

  [status]
  missing_tools = "if_other_versions_installed"
  show_env = false
  show_tools = false

No warnings found
No problems found
winstontsai commented 2 months ago

Ok I figured out it's related to some PATH manipulation.

Basically, at the end of my .bashrc I have some code to deduplicate my PATH. Before that, I also have Homebrew activation, and it turns out that Homebrew activation prepends some entries into PATH that results in a duplicate. Between my Homebrew activation and the PATH deduplication, I have mise activation. So __MISE_ORIG_PATH still has the duplicate entry, e.g. /usr/local/bin:/usr/local/sbin:/usr/local/bin:... but after .bashrc is complete the second duplicate /usr/local/bin has been removed.

If I comment out the PATH deduplication in my .bashrc I can no longer reproduce the issue. However, I'm not sure of the exact mechanics around __MISE_ORIG_PATH which could cause opening a new integrated terminal to affect the original integrated terminal.

If anyone has an explanation for this that would be great.

winstontsai commented 2 months ago

I'm thinking once the terminal is initialized, the __MISE_ORIG_PATH is not a substring of the PATH variable because of the deduplication. This effectively means mise always uses the aggressive PATH update and puts its stuff at the front.

Still need to figure out why opening a new integrated terminal in VS Code triggers mise to recalculate PATH in the original integrated terminal.

winstontsai commented 2 months ago

Unrelated to VS Code. I believe opening any new terminal triggers mise hook-env in other terminals. Don't know why though.