Autovox: [bug, feature] Allow subfolder virtualenvs

eode commented 2 years ago

This is both a feature request and a bug report, but the two are so directly related that I figured they should be included together.

Note that although the xontrib avox is mentioned here, the underlying features are provided by autovox of Xonsh proper.

Bug

When in a subdir within a recognized avox dir that triggers a virtual environment, typing avox create replies with "Working directory already has a virtual environment" -- but then proceeds to exit that virtual environment. When using cd to navigate out of the dir that has the virtualenv associated, it causes a traceback:

Example:


user@host ~/Projects $ mkdir -p example/foo
user@host ~/Projects $ cd example
user@host ~/Projects/example $ avox create
Creating virtual environment example...
Using Interpreter: /usr/bin/python3
Activating...
(example) user@host ~/Projects/example $ cd foo
(example) user@host ~/Projects/example/foo $ avox create
Working directory already has a virtual environment.
user@host ~/Projects/example/foo $ cd ..
user@host ~/Projects/example $ cd ..
xonsh: To log full traceback to a file set: $XONSH_TRACEBACK_LOGFILE = <filename>
Exception raised in event handler; ignored.
Traceback (most recent call last):
  File "/path/to/lib/python3.10/dist-packages/xonsh/__amalgam__.py", line 9768, in fire
    rv = handler(**kwargs)
  File "/path/to/lib/python3.10/dist-packages/xontrib/autovox.py", line 85, in cd_handler
    check_for_new_venv(Path(newdir), Path(olddir))
  File "/path/to/lib/python3.10/dist-packages/xontrib/autovox.py", line 77, in check_for_new_venv
    vox.deactivate()
  File "/path/to/lib/python3.10/dist-packages/xontrib/voxapi.py", line 397, in deactivate
    raise NoEnvironmentActive("No environment currently active.")
xontrib.voxapi.NoEnvironmentActive: No environment currently active.
user@host ~/Projects $

Feature Request

It would be very nice to be able to have nested venvs.

The use case is repositories that have a venv that is typically used, but have subprojects that use a different venv.

Although I think they should be truly nested, that's not an important feature, and it's not what vox does. So, the desired behavior would be:

when creating a new venv, or when entering a dir with a different avox-managed venv, first deactivate the current avox-managed venv (if any).
when deactivating a venv, traverse the parents to find the nearest avox-managed venv. If present, activate it.

Alternatively, "true" nesting would activate each virtualenv successively, but I don't know if venv supports that.

In any case, thanks for your this feature in general, it has been very useful.

xonfig

``` $ xonfig ```

Expected Behavior

Current Behavior

Traceback (if applicable)

``` traceback ```

Steps to Reproduce

For community

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

eode commented 2 years ago

Are you open to PRs?

gforsyth commented 2 years ago

Hey @eode -- sorry for the radio silence on this. I don't use virtualenv myself but we are certainly open to PRs to improve xonsh and/or xontribs

xonsh / xontrib-vox