Closed meatballs closed 4 years ago
Sounds like I need to disallow empty projects.
Note that it takes a directory where you keep your projects, ie mine is ~/code
so I have projects like ~/code/xontrib-avox
and my venv for it would be xontrib-avox
.
Yep, my PROJECT_DIRS is ['~/projects']
and this was done within a sub-folder of that.
It's an existing project, not an empty folder.
What platform are you on?
OSX El Capitan
If you cd into your project and run:
from xontrib.avox import _AvoxHandler
_AvoxHandler().envForNew()
What does it print out?
the folder I'm in is ~/projects/axelrod-python/Axelrod
from xontrib.avox import _AvoxHandler
_AvoxHandler().envForNew()
gives 'axelrod-python/Axelrod'
Looks like it has too much of the path in there.
Nope, that's exactly right. I wanted vox to have support for organized environments, not just a flat space.
This might be a bug in the underlying vox library. Does vox create axelrod-python/Axelrod
work or produce the same result?
vox gets it correct. It creates an axelrod-python
folder in ~/.virtualenvs
and then an Axelrod
environment in there which I can activate with vox activate Axelrod
and now, changing directory back into my project folder is failing with a key error.
That's odd twice over.
avox is just a policy wrapper around vox. Vox is still doing all the hard work. The output of envForNew()
is used as the argument for Vox.create()
--it should be equivalent to vox create
.
You should need to refer to the environment by the full name. Vox doesn't go searching through subdirs to do activations. That is, vox activate Axelrod
should fail but vox activate axelrod-python/Axelrod
should work.
KeyError from whom?
Also, with the new release of avox, an error should not prevent changing the directory.
File "/usr/local/lib/python3.5/site-packages/xontrib/voxapi.py", line 170, in __getitem__
raise KeyError()
It did still change directory.
Now that's wacky. What's the full backtrace?
Traceback (most recent call last):
File "/usr/local/lib/python3.5/site-packages/xonsh/__amalgam__.py", line 9421, in wrapped_simple_command
r = f(args, i)
File "/usr/local/lib/python3.5/site-packages/xontrib/vox.py", line 154, in handle
return vox(args, stdin=stdin)
File "/usr/local/lib/python3.5/site-packages/xontrib/vox.py", line 86, in __call__
getattr(self, 'cmd_'+cmd)(args, stdin)
File "/usr/local/lib/python3.5/site-packages/xontrib/vox.py", line 138, in cmd_remove
del self.vox[name]
File "/usr/local/lib/python3.5/site-packages/xontrib/voxapi.py", line 259, in __delitem__
env_path = self[name].env
File "/usr/local/lib/python3.5/site-packages/xontrib/voxapi.py", line 170, in __getitem__
raise KeyError()
KeyError
That's from vox remove axelrod-python/Axelrod
?
whoops. yes. wrong one.....
Traceback (most recent call last):
File "/usr/local/lib/python3.5/site-packages/xonsh/__amalgam__.py", line 9421, in wrapped_simple_command
r = f(args, i)
File "/usr/local/lib/python3.5/site-packages/xontrib/avox.py", line 155, in cd_handler
self.vox.activate(newve)
File "/usr/local/lib/python3.5/site-packages/xontrib/voxapi.py", line 217, in activate
env_path, bin_path = self[name]
File "/usr/local/lib/python3.5/site-packages/xontrib/voxapi.py", line 170, in __getitem__
raise KeyError()
KeyError
I'm reproducing that on my end, but it's extra wacky. avox should only be trying to activate environments that exist (_AvoxHandler.env()
checks parent directories until it reaches the project root or it finds a valid environment.)
Weirdly, it's only happening for the top directory, not the subdirs.
Ohhhhhh!!!!!!!
I'm reproducing that on my end
Marvellous! At least my own sanity is restored!!
Filed as xonsh/xonsh#1689 and xonsh/xontrib-vox#6. Hopefully I'll have time to fix them tonight (busy kind of day), but it won't be released for a few weeks. (xonsh is on a month-ish release schedule.)
I think this is just a vox issue, but I'm keeping it open until I'm sure.
Submitted as xonsh/xonsh#1727. Rumor is that there may be a new xonsh release in a little while.
Running
avox new
within a project directory gives the following messages:However, no environment is activated.
vox list
then shows no environment with a name matching the project directory. It does show three new environments namedbin
,include
andlib
running
avox new
once again gives:and
avox remove
gives:removing the
bin
,include
andlib
folders from my virtualenvs directory puts me back where I started.