Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mise run --cd option is panicing #1844

Closed
joshbode opened this issue Mar 30, 2024 · 1 comment
Closed

mise run --cd option is panicing #1844

joshbode opened this issue Mar 30, 2024 · 1 comment
Labels
bug Something isn't working

Comments

@joshbode
Copy link
Contributor

Description
When the -C/--cd option is used with mise run the command panics.

To Reproduce
Create a directory with a .mise.toml with the following contents:

$ cat /tmp/foo/.mise.toml
[env]
FOO=123

[tasks.get_env]
run = 'printenv "$@"'

The task will execute as expected if running from the target directory (note: I'm using the shims and shell hooks):

$ cd /tmp/foo

$ echo $FOO
123

$ printenv FOO
123

$ mise run get_env FOO
[get_env] $ printenv "$@"
123

However, if the -C/--cd option is used, then I get a panic:

$ cd /tmp

$ export RUST_BACKTRACE=1

$ mise run -C /tmp/foo get_env FOO
The application panicked (crashed).
Message:  Mismatch between definition and access of `cd`. Could not downcast to TypeId { t: 113748309191418191917298836948495794923 }, need to downcast to TypeId { t: 147963437875188584260812411993370060665 }

Location: /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/index.crates.io-6f17d22bba15001f/clap_builder-4.5.2/src/parser/error.rs:32

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 8 frames hidden ⋮
   9: mise::config::settings::Settings::add_cli_matches::h9fd0e7c302c03418
      at <unknown source file>:<unknown line>
  10: mise::cli::Cli::run::heea91d526ac28f59
      at <unknown source file>:<unknown line>
  11: mise::main::h6d60340e59b266c1
      at <unknown source file>:<unknown line>
  12: std::sys_common::backtrace::__rust_begin_short_backtrace::h96cd15775b13fe1a
      at <unknown source file>:<unknown line>
  13: _main<unknown>
      at <unknown source file>:<unknown line>

Interestingly, the error is slightly different when the -C/--cd option is moved to the top level:

$ mise -C /tmp/foo run get_env FOO
The application panicked (crashed).
Message:  Mismatch between definition and access of `cd`. Could not downcast to TypeId { t: 147963437875188584260812411993370060665 }, need to downcast to TypeId { t: 113748309191418191917298836948495794923 }

Location: /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/index.crates.io-6f17d22bba15001f/clap_builder-4.5.2/src/parser/error.rs:32

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
                                ⋮ 8 frames hidden ⋮
   9: <mise::cli::run::Run as clap_builder::derive::FromArgMatches>::from_arg_matches_mut::h064e4b1f2bbf8f87
      at <unknown source file>:<unknown line>
  10: mise::cli::Cli::run::heea91d526ac28f59
      at <unknown source file>:<unknown line>
  11: mise::main::h6d60340e59b266c1
      at <unknown source file>:<unknown line>
  12: std::sys_common::backtrace::__rust_begin_short_backtrace::h96cd15775b13fe1a
      at <unknown source file>:<unknown line>
  13: _main<unknown>
      at <unknown source file>:<unknown line>

note: the TypeIds are permuted in this case. Looking at the source, it appears that the cd option is defined at the top-level for mise command (as type String) and also for the run (as type PathBuf). It is not defined separately for the exec command, which is probably why it runs OK (though possibly is not operating as expected for a different reason - see #1843)

Expected behavior

The command should not crash and should resolve the environment variable (note: this may also fail to do so due to #1843)

mise doctor output

$ mise doctor

version: 2024.3.9 macos-arm64 (2024-03-24)
activated: yes
shims_on_path: yes

build_info: 
  Target: aarch64-apple-darwin
  Features: DEFAULT, NATIVE_TLS
  Built: Sun, 24 Mar 2024 17:00:58 +0000
  Rust Version: rustc 1.76.0 (07dca489a 2024-02-04) (Homebrew)
  Profile: release

shell: 
  /bin/zsh
  zsh 5.9 (x86_64-apple-darwin23.0)

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

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

plugins: 
  bun     (core)
  deno    (core)
  erlang  (core)
  go      (core)
  java    (core)
  node    (core)
  poetry  https://github.com/mise-plugins/mise-poetry.git#37df872
  python  (core)
  ruby    (core)
  sops    git@github.com:joshbode/mise-sops.git#7558341

toolset: 
  python@3.12.2   
  python@3.11.8   
  python@3.10.14  
  poetry@1.8.2    

env_vars: 
  MISE_SHELL=zsh

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 = true
  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
  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_compile = true
  python_default_packages_file = "/Users/josh/.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 problems found

Additional context
Add any other context about the problem here.

@joshbode joshbode added the bug Something isn't working label Mar 30, 2024
@jdx jdx closed this as completed in cf4f03e Mar 30, 2024
@joshbode
Copy link
Contributor Author

Thanks @jdx!
I've just tested the new version and I can confirm that there is no longer a panic

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant