List all virtualenv - virtualenv

In virtualenvwrapper, is there a simple way to list all virtualenv on my machine?
(like what yolk -l does to list all python packages in the current virtual environment?)
CLARIFICATION: "ls -la" in my env directory does not count. I am looking for a virtualenv or virtualenvwrapper specific command.

You can use the lsvirtualenv, in which you have two options "long" or "brief":
"long" option is the default one, it searches for any hook you may have around this command and executes it, which takes more time.
"brief" just take the virtualenvs names and prints it.
brief usage:
$ lsvirtualenv -b
long usage:
$ lsvirtualenv -l
if you don't have any hooks, or don't even know what i'm talking about, just use "brief".

To list all the virtual environments (if using the anaconda distribution):
conda info --envs
Hope my answer helps someone...

Silly question. Found that there's a
lsvirtualenv
command which lists all existing virtualenv.
See the command documentation.

If you are using virtualenv or Python 3's built in venv the above answers might not work.
If you are on Linux, just locate the activate script that is always present inside a env.
locate -b '\activate' | grep "/home"
This will grab all Python virtual environments present inside your home directory.
For Mac Users, find works pretty good too
find $HOME -name "*activate" -type f
See Demo Here

Run workon with no argument to list available environments.

For conda created env use:
conda info --envs # or
conda info -e # or
conda env list
For virtualenvwrapper created env use:
lsvirtualenv

If you came here from Google, trying to find where your previously created virtualenv installation ended up, and why there is no command to find it, here's the low-down.
The design of virtualenv has a fundamental flaw of not being able to keep track of it's own created environments. Someone was not quite in their right mind when they created virtualenv without having a rudimentary way to keep track of already created environments, and certainly not fit for a time and age when most pip requirements require multi-giga-byte installations, which should certainly not go into some obscure .virtualenvs sub-directory of your ~/home.
IMO, the created virtualenv directory should be created in $CWD and a file called ~/.virtualenv (in home) should keep track of the name and path of that creation. Which is a darn good reason to use Conda/Miniconda3 instead, which does seem to keep good track of this.
As answered here, the only way to keep track of this, is to install yet another package called virtualenvwrapper. If you don't do that, you will have to search for the created directory by yourself. Clearly, if you don't remember the name or the location it was created with/at, you will most likely never find your virtual environment again...
One try to remedy the situation in windows, is by putting the following functions into your powershell profile:
# wrap virtualenv.exe and write last argument (presumably
# your virtualenv name) to the file: $HOME/.virtualenv.
function ven { if( $args.count -eq 0) {Get-Content ~/.virtualenv } else {virtualenv.exe "$args"; Write-Output ("{0} `t{1}" -f $args[-1],$PWD) | Out-File -Append $HOME/.virtualenv }}
# List what's in the file or the directories under ~/.virtualenvs
function lsven { try {Get-Content ~/.virtualenv } catch {Get-ChildItem ~\.virtualenvs -Directory | Select-Object -Property Name } }
WARNING: This will write to ~\.virtualenv...
If you use the recommended venvlink, then you can add the following powershell function, to list your available virtual environments.
# List what's in the directories of C:\venvs\
# - installed venvlink, with venvs in C:\venvs\
# - venvlink uses: ~/.venvlinkrc
function lsven { Get-ChildItem -Path C:\venvs\ -Name }
This can surely be improved to automatically detect the venvlink root directory.

To list all virtualenvs
conda env list
Output:
# conda environments:
#
D:\Programs\Anaconda3
D:\Programs\Anaconda3\envs\notebook
D:\Programs\Anaconda3\envs\snakes
D:\Programs\Anaconda3\envs\snowflakes
base * D:\Programs\Miniconda3
gluon D:\Programs\Miniconda3\envs\gluon

If using Anaconda conda env list
If using Python3 lsvirtualenv after you installed pip install virtualenvwrapper

Use below bash command to locate all virtual env in your system. You can modify the command according to your need to get in your desired format.
locate --regex "bin/activate"$ | sed 's/bin\/activate$//'

How do I find the Django virtual environment name if I forgot?. It is very Simple, you can find from the following location, if you forgot Django Virtual Environment name on Windows 10 Operating System.
c:\Users<name>\Envs<Virtual Environments>

The best answer I can find is we can check the installed python directory.
As for windows, the default directory for virtualenv and pipenv is.
/c/User/<username>/.virtualenv/
The directory(folder) inside the above directory shows all virtualenvs
Example -
ankit#ankit-PC MINGW64 ~/Desktop/study
$ ls /c/Users/ankit/.virtualenvs/
get_env_details* postactivate* postmkproject* postrmvirtualenv* predeactivate* premkvirtualenv* study-OwW1UW_H/
initialize* postdeactivate* postmkvirtualenv* preactivate* premkproject* prermvirtualenv*
study-OwW1UW_H/ is the only directory and virtualenv in the above example.

This works on Windows only:
If you are trying to find all envs created using virtualenv
search for "activate_this.py" or "pip-selfcheck.json"

if you're working on windows and conda, typing conda info --envs in cmd will show all the existing virtual envirentment.

Related

Set global environment variables in VS Code with remote-ssh

I have the case that I need to use VS Code installed on Windows 10 and run it with the extension Remote - SSH on a RHEL 7.x.
The default RHEL 7.x runs with git 1.8.x. I have installed a newer git version but this is not in the default $PATH environment.
I have found this instructions https://code.visualstudio.com/docs/remote/wsl#_advanced-environment-setup-script which describe how to set the environment variables specifically for VS Code when usind WSL.
If you want to run additional commands or modify the environment this can be done in a setup script ~/.vscode-server/server-env-setup
This does seem to work only if you use WSL. Why does this not work with the Remote - SSH extension?
My special case is that I only want and need the git>=2 while usind VS Code. When I am connected regularly via ssh I would like and need the OS default tools and settings.
This gives me the special request that I don't want to edit the ~/.bashrc, ~/.cshrc or any other user environment files.
I would like to be able to edit the environment for VS Code only. Some kind, maybe like:
#!/bin/bash
export PATH=/opt/rh/rh-git29/root/usr/bin\:$PATH
export LD_LIBRARY_PATH=/opt/rh/httpd24/root/usr/lib64:$LD_LIBRARY_PATH
...
#!/bin/csh
setenv PATH /opt/rh/rh-git29/root/usr/bin\:$PATH
setenv LD_LIBRARY_PATH /opt/rh/httpd24/root/usr/lib64:$LD_LIBRARY_PATH
...
Is there anything I have not found yet where I can make my requests to work or would this be some kind of request to the VS Code Team?
Regards.
I think I found the solution in this issue comment and the follow-up response:
When vscode-server initially starts, it uses a login shell, sourcing .profile in your home directory.
However, any following interactive shells started through VS Code are non-login shells and thus only source .bashrc
A complication in fiddling with this is that vscode-server apparently caches the environment during its lifetimes, so changes to these dotfiles don't become visible until the server is restarted.
I have a better solution to minimize the proxy scope
export http_proxy=<proxy here>
export no_proxy=<no proxy here>
while IFS= read -r _file; do
if ! grep -s -q "export http_proxy=" "${_file}"; then
sed -i -e "/^ROOT/i export http_proxy=${http_proxy}" -e "/^ROOT/i export https_proxy=${http_proxy}" -e "/^ROOT/i export no_proxy=${no_proxy}" "${_file}"
fi
done < <(find ~/.vscode-server/bin -type f -name "server.sh")

how to specify new environment location for conda create

the default location for packages is .conda folder in my home directory. however, on the server I am using, there is a very strict limit of how much space I can use, which basically avoids me from putting anything under my home directory. how can I specify the location for the virtual environment that I want to create? Thanks! server is running Ubuntu.
Use the --prefix or -p option to specify where to write the environment files. For example:
conda create --prefix /tmp/test-env python=2.7
Will create the environment named /tmp/test-env which resides in /tmp/ instead of the default .conda.
like Paul said, use
conda create --prefix=/users/.../yourEnvName python=x.x
if you are located in the folder in which you want to create your virtual environment, just omit the path and use
conda create --prefix=yourEnvName python=x.x
conda only keep track of the environments included in the folder envs inside the anaconda folder. The next time you will need to activate your new env, move to the folder where you created it and activate it with
source activate yourEnvName
While using the --prefix option works, you have to explicitly use it every time you create an environment. If you just want your environments stored somewhere else by default, you can configure it in your .condarc file.
Please see: https://conda.io/docs/user-guide/configuration/use-condarc.html#specify-environment-directories-envs-dirs
If you want to use the --prefix or -p arguments, but want to avoid having to use the environment's full path to activate it, you need to edit the .condarc config file before you create the environment.
The .condarc file is in the home directory; C:\Users\<user> on Windows. Edit the values under the envs_dirs key to include the custom path for your environment. Assuming the custom path is D:\envs, the file should end up looking something like this:
ssl_verify: true
channels:
- defaults
envs_dirs:
- C:\Users\<user>\Anaconda3\envs
- D:\envs
Then, when you create a new environment on that path, its name will appear along with the path when you run conda env list, and you should be able to activate it using only the name, and not the full path.
Command line screenshot
In summary, if you edit .condarc to include D:\envs, and then run conda env create -p D:\envs\myenv python=x.x, then activate myenv (or source activate myenv on Linux) should work.
Hope that helps!
P.S. I stumbled upon this through trial and error. I think what happens is when you edit the envs_dirs key, conda updates ~\.conda\environments.txt to include the environments found in all the directories specified under the envs_dirs, so they can be accessed without using absolute paths.
You can create it like this
conda create --prefix C:/tensorflow2 python=3.7
and you don't have to move to that folder to activate it.
# To activate this environment, use:
# > activate C:\tensorflow2
As you see I do it like this.
D:\Development_Avector\PycharmProjects\TensorFlow>activate C:\tensorflow2
(C:\tensorflow2) D:\Development_Avector\PycharmProjects\TensorFlow>
(C:\tensorflow2) D:\Development_Avector\PycharmProjects\TensorFlow>conda --version
conda 4.5.13
I ran into a similar situation. I did have access to a larger data drive. Depending on your situation, and the access you have to the server you can consider
ln -s /datavol/path/to/your/.conda /home/user/.conda
Then subsequent conda commands will put data to the symlinked dir in datavol
You can modify the default paths for environments by modifying CONDA_ENVS_PATH:
For macOS and Linux: CONDA_ENVS_PATH=~/my-envs:/opt/anaconda/envs
For Windows: set CONDA_ENVS_PATH=C:\Users\joe\envs;C:\Anaconda\envs
the documentation is here:
https://conda.io/projects/conda/en/latest/user-guide/configuration/use-condarc.html#specify-environment-directories-envs-dirs
Use -p option to specify the path to your env.
For Linux/macOS, env location info is stored in ~/.conda/environments.txt.
Use conda info --envs to list all your envs.

Forgot virtualenv name - how to find the name of the virtual env?

I set up a flask site with uwsgi/nginx a while back, and set up a virtualenv.. I've forgotten the name of the venv I set up, and I can't find any way to list the virtualenv in a current dir.
How do I find out the name of my virtualenv?
If it’s definitely in the current directory, try ls */bin/python. Otherwise, ls **/python, or find . -name python. You can, of course, just make a new one, too.
If it is a conda virtualenv you can do the following:
conda info --envs
Now, Select your virtual environment and perform this:
conda activate <your_env>

Sublime Text CoffeeScript build system: `env: node: No such file or directory`

I'm trying to set up a CoffeeScript build system in Sublime Text 3, but I keep getting the following error:
env: node: No such file or directory
[Finished in 0.0s with exit code 127]
[cmd: ['coffee', '-o','/Users/jcourtdemone/Sites/autotempest.com/new_design_sandbox/static/script', '-cw', '/Users/jcourtdemone/Sites/autotempest.com/new_design_sandbox/static/coffee']]
[dir: /Users/jcourtdemone/Sites/autotempest.com/new_design_sandbox/static/coffee]
[path: /usr/bin:/bin:/usr/sbin:/sbin]
My build system looks like this:
{
"name": "Coffee - AT",
"cmd": ["coffee","-o","${project_path:${folder}}/static/script","-cw","${project_path:${folder}}/static/coffee"],
"selector": "source.coffee",
"path":"/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/lib/node_modules/coffee-script/bin"
}
Two things strange about this.
1) It says it's looking in /usr/bin where a symlink to coffee exists.
2) Because of (1), I overrode $PATH to include the actual location of coffee which is /usr/local/lib/node_modules/coffee-script/bin, but for some reason, $PATH isn't being overridden properly, it's sticking with the default $PATH.
Things to note:
i) I've verified that all paths are correct and pass normally through a regular terminal command.
ii) Tried with a "shell": true variable in the build system.
iii) I have another build system for Compass like this that works fine.
Anyone run into similar problems or issues? Any ideas?
In Terminal, type which node, then create a symlink to that location in /usr/bin. For example, if node lives in /usr/local/bin, create the symlink like so:
sudo ln -s /usr/local/bin/node /usr/bin/node
If you look at the source of your coffee script, you'll probably find that the first line is something along the lines of:
#!/usr/bin/env node
Exit code 127 in Sublime means that an env command has failed - so in your case, the build system is finding coffee, but it can't execute it because the node binary isn't in Sublime's default search path.
There are two ways to redefine the default search path for Sublime. The first (and easiest) is to always open it from the command line using the built-in subl command. If you're an OS X power user and don't mind messing with important system settings, check out my post on unix.SE on how to alter the default /usr/bin:/bin:/usr/sbin:/sbin path that you're seeing. Be forewarned that if you don't do things correctly, you may break your system. However, if you're running Mountain Lion (10.8.X) and you follow the instructions exactly, everything should be fine. (I haven't upgraded to Mavericks, so no guarantees on whether it'll work with that version.)
How to solve the problem under an Ubuntu System
The fact is "coffee" command will call /usr/bin/node to continue its work, however, the original "node" command for the node application on an Ubuntu system is changed from "node" to "nodejs" to avoid name conflicting. That is the reason, the shell will compliant you "/usr/bin/env: node: No such file or directory". whenever you type
$ coffee
To solve the bug, just let the shell find something named "node" in its default searching path, and this so-called "node" will promote nodejs. The command "nodejs" lies under path of /usr/bin/nodejs.
We will use symbol link to link "node" with nodejs, and place the link "node" within the default searching path, so that the shell will find it.
sudo ln -s /usr/bin/nodejs /usr/bin/node
But beware, make sure that you do NOT have another "node" command under /usr/bin/, you can check it by try to run
$ which node
I do NOT know what to do if you have installed another "node" application.
In Ubuntu you can install the package nodejs-legacy
sudo apt-get install nodejs-legacy
this package just create a symbolic link to binary nodejs
You should be able to fix this all in your build system without needing to add a symlink on your machine.
For example if node lives in /usr/local/bin/node all you have to do is change the path in your build_system to be:
"path": "/usr/local/bin:$PATH"
I had the same problem with Sublime Text 2.
Creating this sublime build worked for me:
{
"cmd": ["coffee", "-c", "$file"],
"selector" : "source.coffee",
"path" : "/usr/local/lib/node_modules/coffee-script/bin/:/usr/local/bin:$PATH"
}
The following code worked for me in Ubuntu 14.04:
**$ sudo apt-get install NodeJS-legacy**
The other problem was the version checking frameworks such as for e.g: gulp -v the same code also solved this problem.
Type the next in the console:
sudo ln -s /usr/bin/nodejs /usr/bin/node

swlist command to get software installed on different system

When you run swlist with no arguments on an HPUX system you get the packages that are installed on that particular host. I want that same output but instead listing packages that are installed on a different system.
Is this possible?
find $(perl -e 'print"#INC"') -name \*.pm
will get you most of the way there.
Try using Net::SSH::Expect to execute the swlist command on the remote host, grab the output and do what you want with it. That's what I would do.