Open ghost opened 4 years ago
That's.... odd.
In my local version, I get this:
🐚 vox create tmp
Creating environment...
Environment 'tmp' created. Activate it with "vox activate tmp".
🐚 vox activate tmp
Activated "tmp".
🐚 vox remove tmp
The "tmp" environment is currently active. In order to remove it, deactivate it first with "vox deactivate tmp".
(Now, if you delete the venv directory out from under vox, I could see things getting funky.)
Yes, that's why you need to have (at least) 2 Xonsh instances running (and do the vox remove ...
in a different Xonsh instance then the one where the venv is not active) when using vox
for the removal ;)
Ahhh, I see.
Yeah, that'll probably cause problems.
xonfig
Clean install (inside a temp virtualenv), started as
xonsh --no-rc
Expected Behavior
The old virtualenv should be deactivated and the new virtualenv should be activated
Current Behavior
An error message is shown, old virtualenv is deactivated but new virtualenv isn't activated.
Steps to Reproduce
Open 2 xonsh instances.
In xonsh instance 1:
In xonsh instance 2:
or just remove or rename the virtualenv directory directly.
Back in xonsh instance 1:
Note that a second
vox activate bar
does succeed (as thefoo
virtualenv has been deactivated by the first attempt):Additional info
Some quick debugging seems to indicate the problem is due to https://github.com/xonsh/xonsh/blob/master/xontrib/voxapi.py#L288 , the
ve.bin
dir doesn't exist (obviously, the virtualenv got removed ;) ) so theelse:
part of the for loop gets triggered, raising aKeyError
. This gets caught by theexcept KeyError:
part incmd_activate()
( https://github.com/xonsh/xonsh/blob/master/xontrib/vox.py#L161 ).For community
⬇️ Please click the 👍 reaction instead of leaving a
+1
or 👍 comment