After downloading and unarchiving xonsh-master.zip, and then following the "Windows Install from Source" directions at https://xon.sh/windows.html, the following (abbreviated) console output was generated;

python -m venv TEST_XONSH
TEST_ONSH\Scripts\activate.bat
(TEST_ONSH) > pip list
Package Version

pip 10.0.1
setuptools 39.0.1

(TEST_XONSH) xonsh-master>python
Python 3.7.1 (v3.7.1:260ec2c36a, Oct 20 2018, 14:57:15) [MSC v.1915 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

^Z

(TEST_ONSH) > pip install prompt-toolkit
(TEST_ONSH) > pip list
Package Version

pip 19.1.1
prompt-toolkit 2.0.9
setuptools 39.0.1
six 1.12.0
wcwidth 0.1.7
(TEST_ONSH) > cd xonsh-master
(TEST_ONSH) xonsh-master> python setup.py install
<<much output deleted, which I have if questions arise.>>
(TEST_XONSH) > xonsh-master>xonsh
xonsh-master\xonsh_amalgam_.py:16197: UserWarning: prompt_toolkit is not available, using readline instead.
"prompt_toolkit is not available, using " "readline instead."
Skipping setup. Because no readline implementation available.
Please install a backend (readline, prompt-toolkit, etc) to use
xonsh interactively.
See xonsh/xonsh#1170

After looking at xonsh code and sampling sys.path at runtime, I determined what the problem and fix was...

The reason this error happens is because the xonsh.bat file is making decisions about what Python interpreter to use; namely the one in C:\Windows\py.exe (who put that there??) rather than the one in the defined virtual env.

Replacing xonsh.bat with just the single line:
python -m xonsh %*
fixes the problem; so does just invoking the xonsh module like this:

(TEST_XONSH) xonsh-master>python -m xonsh --version
xonsh/0.9.6

My expectations were that the application would do nothing to automatically select a python interpreter; since the virtual environment creation and "activation" takes care of all those details so the virtual environment is usable.

I am looking forward to playing with xonsh. Thanks for working so hard, writing so much code, and releasing it for others to use!!

For community

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

When deleting an organized venv (ie, has a slash in it), the empty parent directory is not removed with it.

For community

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

Basically, a magic command that will apply the named venv to the prompt, or create a new prompt in the venv, without having to install xonsh & xontribs into the venv.

For community

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

Trying to create a venv for a new project, but vox new has a few bugs I ran afoul of when trying to combine various of its CLI flags:

vox new -p python3.11 --copies -a -i pytermgui -i pudb -l new_venv_name:

Creates venv, then exits with "xonsh.tools.XonshError: No virtualenv is found".
Does not activate the new venv (-a)
Does not install the given packages (-i)
Does not set the current path to be that venv's project (-l)
I had to delete the -l (and the -is, see below), as linking the current dir seems to be what causes the error.
I'm not sure what --copies does; I thought it would make the python binaries in the venv be copied from the system instead of symlinking them, but they are still symlinked. So this option might also be buggy.

vox new -i pytermgui -i pudb new_venv_name

When experimenting which arguments are incompatible with each other, I found that the above line immediately fails with vox new: error: the following arguments are required: ENV. It does not recognise the new venv's name.

Setting $VIRTUALENV_HOME to ~/.local/envs causes environments to be created in ~/\~/.local/envs (e.g. /Users/username/~/.local/envs). It would be nice if one didn't have to call os.expanduser when setting the environment variable.

xonfig

Clean install (inside a temp virtualenv), started as xonsh --no-rc

$ xonfig
+------------------+----------------------+
| xonsh            | 0.9.13.dev1          |
| Git SHA          | 9f7ccc65             |
| Commit Date      | Oct 15 17:14:50 2019 |
| Python           | 3.6.9                |
| PLY              | 3.11                 |
| have readline    | True                 |
| prompt toolkit   | 3.0.3                |
| shell type       | prompt_toolkit2      |
| pygments         | 2.5.2                |
| on posix         | True                 |
| on linux         | True                 |
| distro           | unknown              |
| on darwin        | False                |
| on windows       | False                |
| on cygwin        | False                |
| on msys2         | False                |
| is superuser     | False                |
| default encoding | utf-8                |
| xonsh encoding   | utf-8                |
| encoding errors  | surrogateescape      |
+------------------+----------------------+

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:

$  xontrib load vox
$  vox create foo
$  vox create bar
$  vox activate foo

In xonsh instance 2:

$  vox remove foo

or just remove or rename the virtualenv directory directly.

Back in xonsh instance 1:

$  vox activate bar
This environment doesn't exist. Create it with "vox new bar".

Note that a second vox activate bar does succeed (as the foo virtualenv has been deactivated by the first attempt):

$  vox activate bar
Activated "bar".

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 the else: part of the for loop gets triggered, raising a KeyError. This gets caught by the except KeyError: part in cmd_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

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