Open AstraLuma opened 7 years ago
Hm. Could be done with caching state (sys.path
and $PATH
) and using site.addsitedir().
note: vox has an 'enter' command which is an alias of activate.
@astronouth7303 Could you elaborate a bit more of what you mean? {env_name}
in $PROMPT is already there. Do you mean a feature that would allow setting an unique $PROMPT for every virtual env?
I use something like this with xonsh-autoxsh
~ $ cd ~/test
~/test $ echo "$PROMPT = 'foobar $'" > .autoxsh
~/test $ cd .
Unauthorized ".autoxsh" file found in this directory. Authorize and invoke? (y/n/ignore): y
foobar $ echo "prompt was changed!"
Since it's usually a good idea to use a new virtualenvironment for every project this snipped kinda serves the same purpose.
I mean applying a virtual environment to your xonsh session.
Or maybe spawning a xonsh shell in the environment?
Either way, it involves crossing environments and other weirdness, so it's certainly non-trivial.
@AstraLuma vox activate
already applies virtual environment to the current xonsh session. perhaps you want to spawn a new shell session with the env variable applied, like pew does?
No, the python contents, not just the commands.
No, the python contents, not just the commands.
could you elaborate on this? I still don't get it.
Add the python environment of the venv to xonsh's python environment.
So you have a repl kinda matching the project you're working on.
That can be done by adding site-packages to the PYTHONPATH of the xonsh's venv. I think it should be a separate xontrib than vox itself. It just manages the virtualenv, and to facilitate imports from the current env, seems a different thing.
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