Simple question: is running homebrew while in a virtualenv a bad idea?
If so, is there any way that I can automatically deactivate the virtualenv each time I run a homebrew command? I don't trust myself to always remember to deactivate the virtualenv or open a new terminal window.
Since I just ran across this myself in the documentation, it's probably better in general not to brew install from within an active virtualenv. To quote from said docs:
WARNING: When you brew install formulae that provide Python bindings, you should not be in an active virtual environment.
Activate the virtualenv after you've brewed, or brew in a fresh Terminal window. Homebrew will still install Python modules into Homebrew's site-packages and not into the virtual environment's site-package.
Virtualenv has a switch to allow "global" (i.e. Homebrew's) site-packages to be accessible from within the virtualenv.
As such, if you are certain the formula you are brewing will not attempt to provide new Python bindings then let it rip. But for me, if there's no specific reason to brew install with my virtual environment activated, I try and remember to deactivate beforehand.
I don't think if they are related. You have to use pip for python package management when you use virtualenv. this way you make sure that your new stuff is on the sandbox you created. AFAIK home-brew installs stuff globally. So better not use it to get the python modules. hope it helps.
Related
Right now I'm trying to install python (3.10) and all further installations on my new pc (windows 10) and so far everything is set up:
Python installed
Windows paths for "Python" & "Python\Scrips"
I am able to call the python and pip version and also install some packages. But after installing virtualenv and creating one the - at the moment - unfixable error appears: I am unable to install packages into the pip-path of the virtualenviroment itself. Whenever I'm trying to run any pip-command I'm getting the following error:
Unable to create process using 'C:\Users\ExampleUser\AppData\Local\Programs\Python\Python310\python.exe "C:\folder\env\Scripts\pip.exe" '
As you can see, it's always refering to the original python-path, but on the other hand it's refering to the pip-path of the virtualenv!? Don't know if it's helpful, but when typing in where python and where pip the paths inside the venv are the first one listed. I've also watched out for no blank spaces in my path...
Unfortunately no explanation out there could help me until now and I never faced this problem on my old machine - mostly the same, except some older version of python, pip and virtualenv.
Does anyone else has an idea what I am missing?
downloading Python 3 at the official website and installing it via express installation
Copy & Paste the standalone python into the /python folder and overwriting the python version
running python -m pip install --upgrade pip in cmd
Now pip and python 3 are installed in their latest version.
It's work for me
Could you use venv to create your virtual environment, instead of virtualenv (given that venv is the recommended way to create virtual environments for Python 3.3, and newer)?
If using venv is an option, this procedure may give you some idea on how to do it.
I have not done any Python development on Windows, but I think the basics would be:
python3 -m venv your-env-directory
your-env-directory\Scripts\activate.bat
If using venv is not an option, maybe you can try specifying the -v flag when running your virtualenv command to increase verbosity so you can further troubleshoot what's going on.
try upgrade pip version python -m pip install --upgrade pip
[ Sorry if this answer turns out to be more of a comment than an answer. I only have 21 reputation, so I cannot comment ]
When trying to install pip packages and run python files, is the CWD (Current Working Directory) C:\folder\env\Scripts? If so, try chaning your CWD to C:\folder. I had a similar problem and doing this fixed it.
You may need to look into a cygwin environment, and look into a chroot or jail environment to run the application without conflict.
Have you tried to use virtualenv-wrapper-win module.
It helps me a lot to manage virtual envs
Life is much easier using Anaconda 3 (it's definitely bloated compared to normal Python though), or use the minimal Miniconda (barebone install, basically just Python + a package manager). You can download it here: https://docs.conda.io/en/latest/miniconda.html#windows-installers
Then you can make a new virtual environment super easy:
conda create -n myenv pip
conda activate
If you have multiple environments you do: conda activate [environment_name]
Now you're in your new environment with pip installed. And you get drop down menus in the Windows menu to get to your new environment too, so there isn't any searching required. They just appear. Now if you want to link Jupyter Notebook or Spyder to the installation, it takes more steps since you need more packages. I used this guide which basically activates Jupyter first, then Spyder IDE. https://medium.com/#apremgeorge/using-conda-python-environments-with-spyder-ide-and-jupyter-notebooks-in-windows-4e0a905aaac5
Since you created the environment with pip added you can pip install whatever packages you need. I had to do this recently with OpenBLAS backed NumPy and SciPy (the defaults from pip, not from conda). Now Miniconda is the closest thing to basic Python installation, and comes with some nice tools to make your life easier. Hopefully this is helpful.
I'm looking for a way to make a virtualenv which will contain just some libraries (which I chose) of the base python installation.
To be more concrete, I'm trying to import my matplotlib to virtualenv during the creation of virtualenv. It can't be installed efficiently with pip or easy_install since it misses some fortran compiler libs. The way I did it until now was to manually copy from:
/usr/lib/python2.7/dist-packages/ to virtualenv_name/lib/python2.7/dist-packages/
However this prevents the manully imported links to be registerd by yolk (which prints all currently available libs in virtualenv).
So, is there a way to do a selective variant of the
virtualenv --system-site-packages
Create the environment with virtualenv --system-site-packages . Then, activate the virtualenv and when you want things installed in the virtualenv rather than the system python, use pip install --ignore-installed or pip install -I . That way pip will install what you've requested locally even though a system-wide version exists. Your python interpreter will look first in the virtualenv's package directory, so those packages should shadow the global ones.
You can use the --system-site-packages and then "overinstall" the specific stuff for your virtualenv. That way, everything you install into your virtualenv will be taken from there, otherwise it will be taken from your system.
I am late to the game using python.3.8 and pip3 on Ubuntu 20.04.
The ONLY way to get rid of the annoying .local install for me was to set an environment variable (bash):
export PYTHONNOUSERSITE="true"
This does not need to be "true" anything will work. I would not go for a 0. ;-)
Install virtual env with
virtualenv --system-site-packages
and use pip install -U to install matplotlib
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.
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.
I'm looking for a way to make a virtualenv which will contain just some libraries (which I chose) of the base python installation.
To be more concrete, I'm trying to import my matplotlib to virtualenv during the creation of virtualenv. It can't be installed efficiently with pip or easy_install since it misses some fortran compiler libs. The way I did it until now was to manually copy from:
/usr/lib/python2.7/dist-packages/ to virtualenv_name/lib/python2.7/dist-packages/
However this prevents the manully imported links to be registerd by yolk (which prints all currently available libs in virtualenv).
So, is there a way to do a selective variant of the
virtualenv --system-site-packages
Create the environment with virtualenv --system-site-packages . Then, activate the virtualenv and when you want things installed in the virtualenv rather than the system python, use pip install --ignore-installed or pip install -I . That way pip will install what you've requested locally even though a system-wide version exists. Your python interpreter will look first in the virtualenv's package directory, so those packages should shadow the global ones.
You can use the --system-site-packages and then "overinstall" the specific stuff for your virtualenv. That way, everything you install into your virtualenv will be taken from there, otherwise it will be taken from your system.
I am late to the game using python.3.8 and pip3 on Ubuntu 20.04.
The ONLY way to get rid of the annoying .local install for me was to set an environment variable (bash):
export PYTHONNOUSERSITE="true"
This does not need to be "true" anything will work. I would not go for a 0. ;-)
Install virtual env with
virtualenv --system-site-packages
and use pip install -U to install matplotlib