We Keep Coding

No pip or conda command found in my virtual env

I was working on project and had setup a virtualenv. Everything was working fine until severe got crashed. When the server rebooted, I see all my installed packages in virtualenv is lost. When I try to install packages using "pip" I see "pip : command not found" error. Later, I found that I have pip command is working outside of virtual env but not inside the virtual env. I am not sure how to solve the pip issue. I have few questions which are as follows:
Do I need to set the path of pip inside virtual env to make it work? if yes, how to set it up?
When I check my virtual env folder inside my repository I see the pip, pip3.... that means the virtual env has pip command but show how it is not able to call it.
Should I delete my virtualenv and create new virtualenv? If yes, how I may affect my existing code.
Or is there any other way. Any help would be appreciated. Thanks

# put conda on PATH like
. '/SOMEWHERE/conda/etc/profile.d/conda.sh'
# then
conda activate
# or look under conda\envs
conda env list
# if you were just using base I'd recommend a create
conda create -n environment_name
# yes then reinstall everything
conda activate environment_name
I like putting conda activate environment_name in an rc/profile depending on your terminal type as to where

What will happen to packages installed when the virtual environment is deleted?

I create a new project with the following commands:
mkdir ~/my_project
python -m venv ~/my_project
source ～/my_project/Scripts/activate
pip install flask
pip install kivy
pip install foo
pip install bar
And let's say that I decide to remove my_project and create a new project:
rm -rf ~/my_project
mkdir ~/new_project
python -m venv ~/new_project
source ~/Scripts/activate
Questions:
What happens to previously installed packages "flask", "kivy", "foo", and "bar"? Do I need to re-install them for my new_project's virtual environment?
If I don't need to re-install these packages, then I am missing the point of virtual environment? I thought the whole point of virtual environment is that packages installed in the virtual environment is isolated in that environment. Can someone elaborate?

Indeed, pip installs libraries into a subdirectory of the virtualenv when the env is active. Anything in there is independent of any system-wide installs, and vice versa. Removing the env obviously removes the stuff in the subdirectories.
On the other hand, virtualenv can optionally fall back to system-installed packages if you let it. The system-wide installs will obviously still be there after you remove the virtualenv.
As an aside, the current activate hard-codes some things so that you cannot even rename a virtualenv directory; you have to zap and reinstall it. Keeping all the things it needs in a requirements.txt or similar is a good way to simplify this process, as well as document the dependencies.

The point of Virtual Environment is to separate your development environment from your actual environment. Different projects have different package dependencies. So for these cases Virtual Environment comes in handy.
If you installed flask, kivy, foo, and bar inside a virtual environment, then YES, you need to install them when you move into another Virtual Environment (That's the whole purpose of Virtula Environment).
If you find that the packages are available globally then may be you are not using it correctly. You need to activate your Virtual Environment before you install anything or the packages will be installed globally.
For your case I can see you are activating before installing packages. So it should work right. you can always use pip freeze to see what packages are installed.

Default libraries in freshly created Python virtual environment

I created a new virtual environment using the python virtualenv tool.
virtualenv venv
I then activated the virtual environment
source venv/bin/activate
Then I did a pip freeze and this is what I got:
(venv)$ pip freeze
Flask==0.10.1
Werkzeug==0.9.6
itsdangerous==0.24
lxml==3.4.0
numpy==1.9.1
pdir==0.2.2
virtualenv==1.11.6
wsgiref==0.1.2
I am wondering how so many libraries got installed when I did not even install anything in the virtual environment explicitly.
UPDATE 1: When some of the answers suggested, I used virtualenv --no-site-packages as well in Step 1, to create a fresh venv and the same problem persisted. As if using the argument had no effect at all.
UPDATE 2: I was able to solve the problem and have posted my experience below. As pointed in the comments; here is a related question; link, that helped me solve the problem.

Those are the libraries that are already installed globally on your system.
Best practice is to use the --no-site-packages option when creating the virtualenv in order to avoid this exact issue.

I was able to solve the problem. In my ~/.bash_profile file; I had the following line which was creating a problem:
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH
As Martin Lewis, pointed out in an answer to this related question, --no-site-packages will remove the standard site-packages directory from sys.path. But anything else that lives in the standard Python path will still remain.
P.S: I am still not sure why virtualenv works this way. Why include the packages that are there on PYTHONPATH. But at least knowing this solves my problem.

See the documentation - The --system-site-packages Option:
If you build with virtualenv --system-site-packages ENV, your virtual
environment will inherit packages from
/usr/lib/python2.7/site-packages (or wherever your global
site-packages directory is).
This can be used if you have control over the global site-packages
directory, and you want to depend on the packages there. If you want
isolation from the global system, do not use this flag.
These libraries are already installed in your system. Unless you specify --no-site-packages, they'll be inherited.

A 'hackish' solution will be to activate virtual environment and run
pip freeze | xargs pip uninstall -y
This will uninstall all those unwanted packages.

Virtualenvwrapper environments not visible in finder or terminal

Using OSX 10.9.2
Just getting to grips with virtualenv and virtualenvwrapper. I am having an issue where the environments I create with virtualenv are visible in both terminal and finder, but environments that I create with virtualenvwrapper are not.
Here are the steps I take in terminal.
virtualenv virt_env/virt1 --no-site-packages
Successfully creates a virtualenv called virt1
source virt1/bin/activate
Activates the virtualenv
(virt1)localhost:virt_env brendan$
I have several of these virtual environments set up and working and I am able to install packages in each, as I would expect. I am able to switch between them and remove them as necessary. I am also able to see them in Finder and in Terminal.
However when I create virtual environments using virtualenvwrapper it appears that I am able to work with them but I am not able to see them.
Here are the steps I take with virtualenvwrapper
localhost:~ brendan$ mkvirtualenv virt_env/virt4
New python executable in virt_env/virt4/bin/python
Installing setuptools, pip...done.
(virt4)localhost:~ brendan$
I am able to work with this e.g.
(virt4)localhost:~ brendan$ sudo easy_install yolk
And I am able to deactivate and reactivate it. e.g.
deactivate
localhost:~ brendan$
workon virt_env/virt4
(virt4)localhost:~ brendan$
But when I go to finder I am only able to see the environments (virt1, virt2, virt3) that I created via virtualenv and not the environments (virt4) that I created using virtualenvwrapper
I am using these tutorials
Virtualenv
Virtualenvwrapper

Make sure that you've defined your WORKON_HOME environment variable to tell virtualenvwrapper where to put your environments (see the documentation)

MacOS X is a Unix-based system, and so doesn't list files and directories whose names begin with a dot. You are probably storing your virtualenvs is a directory called .virtualenvs, which is therefore invisible.
For details of how to find the pesky thing see, for example, http://www.macosxtips.co.uk/index_files/quickly-show-hidden-files.php

System PIP instead of virtualenv PIP by default?

After using virtualenv with pip off-and-on for a couple of days, I've found that the version of PIP that is used after the virtualenv is actived is the global PIP instead of the PIP relative to that environment; such that if you don't set the shell environment variable export PIP_RESPECT_VIRTUALENV=true, pip will install whatever new package (e.g. pip install argparse) to the global scope instead of only to the virtualenv.
I would expect PIP to install to the virtualenv by default, if that virtualenv is activated.
Is there a reasoning behind it not working that way by default?
See explanation here for how PIP_RESPECT_VIRTUALENV works.

When you create a virtualenv, the activate file hardcodes the variable VIRTUAL_ENV to the location in which you first created the root directory. This variable is then exported when you source <your-venv>/bin/activate.
Consequently, if you move the virtualenv directory subsequent to its creation, the hardcoded file path will be incorrect.
Just open <your-venv>/bin/activate in a text editor and make sure VIRTUAL_ENV is set to the new path of your virtualenv directory:
VIRTUAL_ENV="/Full/path/to/<your-venv>"
export VIRTUAL_ENV
before running source <your-venv>/bin/activate again.
Then of course you can test the version of pip with which pip which should produce:
/Full/path/to/<your-venv>/bin/pip
rather than /usr/bin/pip or /bin/pip etc.

It is not the first time I see someone reporting the same issue. I don't know what is happening, but some people discourage the use o source /path/to/venv/bin/activate because it can mess up your $PATH.
There is a way pip will always respect your virtualenv: don't rely on $PATH. Use:
/path/to/venv/bin/pip install MYPACKAGE
It would be nice to find out what is happening to you and share your solution with others. Meanwhile, it may be ok to use the absolute path to pip.