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.
Trying to create a venv for a new project, but
vox newhas 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--copiesdoes; 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_nameWhen 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.