Pipenv plugin deviates from normal pipenv behavior

[thnee]

The pipenv plugin is exhibiting some behaviors that are not consistent with pipenv itself, and this makes it quite annoying to use pipenv through mise.

For comparison, the poetry plugin does not have either of these problems.

Unclear requirement on Python version

It is not possible to install pipenv if any other Python version than 3.11.2 is being used with mise. Pipenv can definitely run on other Python versions. There should be no need to use 3.11.2 specifically.

The readme for the plugin does not state this as an explicit requirement, nor does it explain why.

Example shell session

λ export RUST_BACKTRACE=full
λ export COLORBT_SHOW_HIDDEN=1

λ mise use [email protected]
mise ~/.config/mise/config.toml tools: [email protected]

λ mise install [email protected]
Error: Command '['/home/username/.local/share/mise/installs/pipenv/2024.0.1/bin/python3', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 127.
mise ~/.local/share/mise/plugins/pipenv/bin/install failed
Error: Command '['/home/username/.local/share/mise/installs/pipenv/2024.0.1/bin/python3', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 127.
Error:
   0: ~/.local/share/mise/plugins/pipenv/bin/install exited with non-zero status: exit code 1

Location:
   src/plugins/script_manager.rs:178

Version:
   2024.7.3 linux-x64 (5d74b6b 2024-07-14)

  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BACKTRACE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
   1: color_eyre::config::EyreHook::into_eyre_hook::{{closure}}::h7ac7a355dade4b28
      at <unknown source file>:<unknown line>
   2: eyre::error::<impl eyre::Report>::from_std::h779e7a9be54d9688
      at <unknown source file>:<unknown line>
   3: mise::plugins::script_manager::ScriptManager::run_by_line::h05e06199bb0844e8
      at <unknown source file>:<unknown line>
   4: <mise::backend::asdf::Asdf as mise::backend::Backend>::install_version_impl::hf4990b5dead1fce2
      at <unknown source file>:<unknown line>
   5: mise::backend::Backend::install_version::h603b5921b5dc7015
      at <unknown source file>:<unknown line>
   6: std::sys_common::backtrace::__rust_begin_short_backtrace::h57c94a3789ebcfaa
      at <unknown source file>:<unknown line>
   7: core::ops::function::FnOnce::call_once{{vtable.shim}}::hafa5d5221e935152
      at <unknown source file>:<unknown line>
   8: std::sys::pal::unix::thread::Thread::new::thread_start::h522bc89a54da820a
      at <unknown source file>:<unknown line>

Run with COLORBT_SHOW_HIDDEN=1 environment variable to disable frame filtering.

λ mise use [email protected]
mise ~/.config/mise/config.toml tools: [email protected]

λ mise install [email protected]
[notice] A new release of pip available: 22.3.1 -> 24.1.2
[notice] To update, run: pip install --upgrade pip
mise [email protected] ✓ installed

Automagic project activation is too aggressive

When using the pipenv plugin, it automagically creates a pipenv project. I.e. it creates a Pipfile, and it creates a venv, and it activates the venv.

This behavior is unexpected and undesirable. Especially when trying to use pipenv globally via mise.

This is not how pipenv itself behaves normally. When pipenv is installed to the user site (pip install --user pipenv), it can be used anywhere, and it does not automagically create a Pipfile or venv unless it is asked to do so.

The mise plugin should not alter the behavior / experience of pipenv. If the mise plugin wants to offer additional features, then those features should be configurable, and the default should be to not deviate from normal pipenv behavior.

Example shell session

λ mkdir $HOME/testing
λ cd $HOME/testing

λ touch .mise.toml

λ mise use [email protected]
mise ~/testing/.mise.toml tools: [email protected]
Creating a virtualenv for this project...
Pipfile: /home/username/testing/Pipfile
Using default python from /home/username/.local/share/mise/installs/pipenv/2024.0.1/bin/python3 (3.11.2) to create virtualenv...
created virtual environment CPython3.11.2.final.0-64 in 283ms
  creator CPython3Posix(dest=/home/username/.local/share/virtualenvs/testing-QUtfWjSU, clear=False, no_vcs_ignore=False, global=False)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, wheel=bundle, via=copy, app_data_dir=/home/username/.local/share/virtualenv)
    added seed packages: pip==24.1.2, setuptools==70.1.1, wheel==0.43.0
  activators BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator

✔ Successfully created virtual environment!
Virtualenv location: /home/username/.local/share/virtualenvs/testing-QUtfWjSU
Creating a Pipfile for this project...
Pipfile.lock not found, creating...
Locking [packages] dependencies...
Locking [dev-packages] dependencies...
Updated Pipfile.lock (ed6d5d614626ae28e274e453164affb26694755170ccab3aa5866f093d51d3e4)!

Mise breaks completely when using pipenv plugin and mise venv manager

When a project directory uses mise to manage venvs and uses pipenv at the same time, mise gets completely stuck and there is no output at all. I don't know exactly what is happening, but it seems like some kind of race condition.

Again, this is not how pipenv behaves normally. If pipenv is installed to the user site, it works fine together with mise venv manager.

The only solution I can find to this specific problem is to not use the pipenv plugin in the project directory, and instead use it globally. But then it comes back to the previous point: When pipenv is enabled globally, it tries to automagically create a pipenv project in the home directory, which is undesirable.

As far as I can tell, this makes this plugin unusable.

Example shell session

λ cd $HOME

λ ls -la testing
total 20
drwxr-xr-x  2 username username 4096 Jul 19 17:53 .
drwxr-x--- 18 username username 4096 Jul 19 17:55 ..
-rw-r--r--  1 username username  115 Jul 19 17:53 .mise.toml
-rw-r--r--  1 username username  139 Jul 19 17:51 Pipfile
-rw-r--r--  1 username username  454 Jul 19 17:51 Pipfile.lock

λ cat testing/.mise.toml
[tools]
python = "3.12.4"
pipenv = "2024.0.1"

[env]
_.python.venv = { path = "~/.venvs/testing", create = true }

λ rm -rf ~/.local/share/virtualenvs/testing-QUtfWjSU  # pivenv venv
λ rm -rf ~/.venvs/testing  # mise venv

λ cd testing
It hangs forever with no output.
Even with MISE_DEBUG=1 there is no additional output on what is happening.
And pressing Ctrl+C does not terminate the program correctly, it keeps running.