Default pip install to --user on Windows - python

I am using pip as my package manager for Python on my Windows 11 machine. I always install all my packages to --user. So, having to add --user argument every time I install a package is kind of annoying since it's my desired default installation path already!
> pip install package1 package2 package3 --user
On Ubuntu, if sudo pip is not used (which is recommended not to use it), pip install defaults to user
$ pip install package1 package2 package3
Defaulting to user installation because normal site-packages is not writeable
...
Is there any way to force pip to install packages to user by default as if --user argument is added without explicitly appending it at the end?
I always add --user --upgrade --verbose to any pip install command

You can look at the pip documentation here.
For the following to work you might have to go to File Explorer and at the top go to View and make sure you have selected hidden items from the options.
You will need to specify the default install location within a pip.ini file. Which, is usually located at %APPDATA%\local\pip\pip.ini(on Windows).
The %APPDATA% is located in C:\Users\username then go to AppData on Windows.
You may have to create the pip.ini file when you find your pip directory. Within your pip.ini you will then need to put something like:
[global]
target=C:\Users\user
user being your username for your Windows machine.

Related

How to configure pip so that pip install is always called with argument --user?

I'm configuring a jupyterlab single-user instance. The users will need to install Python packages using
pip install <package-name>
I want to configure pip so that pip install is always called with argument --user, even if it is invoked without --user. Is it possible to achieve this? If so, how?
The reason behind it is that the $HOME directory is mounted on a persistent volume, and I want the user to still have its packages installed after restarting the jupyterlab server. By installing packages using pip install --user <package-name>, the packages will be stored in $HOME/.local/lib/python${PY_MAJOR}.${PY_MINOR}/site-packages and will therefore persist even after a server restart.
A solution that works on ubuntu:
Add this in $HOME/.pip/pip.conf:
[install]
user = yes
Documentation:
https://pip.pypa.io/en/stable/user_guide/#user-installs
https://pip.pypa.io/en/stable/topics/configuration/
https://pip.pypa.io/en/stable/cli/pip_install/#cmdoption-user
pip install <package-name>
#To run this code command prompt on python terminal to install a package
pip install --user
#python packages name on terminal to install with the help of
pycharm

How can I see what packages were installed using `sudo pip install`?

I know that installing python packages using sudo pip install is bad a security risk. Unfortunately, I found this out after installing quite a few packages using sudo.
Is there a way to find out what python packages I installed using sudo pip install? The end goal being uninstallment and correctly re-installing them within a virtual environment.
I tried pip list to get information about the packages, but it only gave me their version. pip show <package name> gave me more information about an individual package such as where it is installed, but I don't know how to make use of that information.
any modules you installed with sudo will be owned by root, so you can open your shell/terminal, cd to site-packages directory & check the directories owner with ls -la, then any that has root in the owner column is the one you want to uninstall.
When you run sudo pip install, pip will install the package in your global site-packages directory.
So, to determine which packages you've installed with sudo pip install, you can navigate to your /site-packages directory.
The site-packages directory is a sub-directory of your python installation. For example, /Users/me/Library/Python/2.7/lib/python/site-packages.
This SO post has a more detailed discussion regarding how to find the site-packages directory.
Hope this helped!
try the following command: pip freeze

Different custom install locations for pip2 and pip3

When using pip with the --user flag, the default installation location is ~/.local/lib/pythonX.Y/site-packages, where X.Y specifiy the version of python. This allows for separation of packages installed using pip2 from those installed via pip3.
However, when using a pip.conf file to specify a target installation directory, I've only seen a global setting such as this:
[global]
target=/data/user/pip
This works, but doesn't separate packages installed by pip2 from those installed via pip3 which can cause issues. Is there a way to specify different locations for packages installed via pip2 and those installed via pip3?
Unfortunately, there's no possibility to handle version-specific stuff in the pip config. The current decision about this is:
...it doesn't appear to be something we actually need.
However, the user installation target is actually configured not via --target, but via the PYTHONUSERBASE environment variable. This means that you can pass the user base from env, for example PYTHONUSERBASE=/some/dir pip install --user pkgname. If you want to persist the custom user base dir, I'd go with an alias. Example for bash: in your .bashrc/.bash_profile, add:
alias pip2='PYTHONUSERBASE=/tmp/pip2 pip2'
alias pip3='PYTHONUSERBASE=/tmp/pip3 pip3'
alias pip3.7='PYTHONUSERBASE=/tmp/pip3.7 pip3.7'
# etc
Save the file, reload with
source ~/.bashrc
or
source ~/.bash_profile
or simply open a new terminal. Now
$ pip2 install --user pkgname
will install to /tmp/pip2 etc.

Shouldn't Python install packages in the directory of it's own?

I have
C:\>where pip3
C:\Python35\Scripts\pip3.exe
C:\Python36\Scripts\pip3.exe
on my Windows 10 box. Simultaneously, when I ran
pip3 install --upgrade --user awscli
I got aws.cmd located in
C:\Users\Dmitry\AppData\Roaming\Python\Python35\Scripts
Was this misconfiguration or expected behavior of awscli installer?
You used the --user option, and the documentation says
Passing the --user option to python -m pip install will install a package just for the current user, rather than for all users of the system.
If the package is supposed to be user-specific it can't go in C:\Python*, because those are system-wide directories, and all users would share them.
So, yes, it's expected that when you request a user-specific installation, the package goes in a user-specific directory.

Bypass confirmation prompt for pip uninstall

I'm trying to uninstall all django packages in my superuser environment to ensure that all my webapp dependencies are installed to my virtualenv.
sudo su
sudo pip freeze | grep -E '^django-' | xargs pip -q uninstall
But pip wants to confirm every package uninstall, and there doesn't seem to be a -y option for pip. Is there a better way to uninstall a batch of python modules? Is rm -rf .../site-packages/ a proper way to go? Is there an easy_install alternative?
Alternatively, would it be better to force pip to install all dependencies to the virtualenv rather than relying on the system python modules to meet those dependencies, e.g. pip --upgrade install, but forcing even equally old versions to be installed to override any system modules. I tried activating my virtualenv and then pip install --upgrade -r requirements.txt and that does seem to install the dependencies, even those existing in my system path, but I can't be sure if that's because my system modules were old. And man pip doesn't seem to guarantee this behavior (i.e. installing the same version of a package that already exists in the system site-packages).
starting with pip version 7.1.2 you can run pip uninstall -y <python package(s)>
pip uninstall -y package1 package2 package3
or from file
pip uninstall -y -r requirements.txt
Pip does NOT include a --yes option (as of pip version 1.3.1).
WORKAROUND: pipe yes to it!
$ sudo ls # enter pw so not prompted again
$ /usr/bin/yes | sudo pip uninstall pymongo
If you want to uninstall every package from requirements.txt,
pip uninstall -y -r requirements.txt
on www.saturncloud.io, Jupiter notebooks one can use like this:
!yes | pip uninstall tensorflow
!yes | pip uninstall gast
!yes | pip uninstall tensorflow-probability
Alternatively, would it be better to force pip to install all dependencies to the virtualenv rather than relying on the system python modules to meet those dependencies,
Yes. Don't mess too much with the inbuilt system installed packages. Many of the system packages, particularly in OS X (even the debian and the derived varieties) depend too much on them.
pip --upgrade install, but forcing even equally old versions to be installed to override any system modules.
It should not be a big deal if there are a few more packages installed within the venv that are already there in the system package, particularly if they are of different version. Thats the whole point of virtualenv.
I tried activating my virtualenv and then pip install --upgrade -r requirements.txt and that does seem to install the dependencies, even those existing in my system path, but I can't be sure if that's because my system modules were old. And man pip doesn't seem to guarantee this behavior (i.e. installing the same version of a package that already exists in the system site-packages).
No, it doesn't install the packages already there in the main installation unless you have used the --no-site-packages flag to create it, or the required and present versions are different..
Lakshman Prasad was right, pip --upgrade and/or virtualenv --no-site-packages is the way to go. Uninstalling the system-wide python modules is bad.
The --upgrade option to pip does install required modules in the virtual env, even if they already exist in the system environment, and even if the required version or latest available version is the same as the system version.
pip --upgrade install
And, using the --no-site-packages option when creating the virtual environment ensures that missing dependencies can't possibly be masked by the presence of missing modules in the system path. This helps expose problems during migration of a module from one package to another, e.g. pinax.apps.groups -> django-groups, especially when the problem is with load templatetags statements in django which search all available modules for templatetags directories and the tag definitions within.
pip install -U xxxx
can bypass confirm

Categories

Resources