Where is site-packages located in a Conda environment?
After installing a package in an Conda environment, I’d like to make some changes to the code in that package. Where can I find the site-packages directory containing the installed packages? I have an Anaconda Python 2.7 base distribution, but I do not find a directory:
/Users/username/anaconda/lib/python2.7/site-packages Important Note: Conda tracks file sizes to detect corruption/package clobbering, and since some files are hardlinked, editing in one environment could lead to corruption in all environments and the package cache. If one plans to edit files manually for a particular package, consider first reinstalling the package in copy-only mode with a conda install —copy —force-reinstall operation.
11 Answers 11
You can import the module and check the module.__file__ string. It contains the path to the associated source file.
Alternatively, you can read the File tag in the the module documentation, which can be accessed using help(module) , or module? in IPython.
My problem is that I get a package import «not found» error for the package that conda supposedly installed. So I would like to check where conda thinks that it installed the package.
@BenFarmer: this sounds like a rather different problem. Have you tried searching for something along the line of «conda list installed package paths»? This returns stackoverflow.com/q/46767012 and stackoverflow.com/q/47138241.
Run this inside python shell:
from distutils.sysconfig import get_python_lib print(get_python_lib()) Linux users can find the locations of all the installed packages like this:
pip list | xargs -exec pip show Updated 2022-03-21 to remove the unwanted table heading at the top of pip list output:
pip list | tail -n +3 | xargs -exec pip show i just used: pip show
@CharlieParker it sounds like you want to be able to list the files in a given conda package: stackoverflow.com/questions/47138241/…. Verify that the package is installed in the correct environment (the one your Python binary is part of), and that it includes files in directories that Python looks at (list those paths with python -m site ).
One more option using the interpreter:
import site; print(».join(site.getsitepackages()))
And using a terminal/prompt:
python -c «import site; print(».join(site.getsitepackages()))»
Also in this case you can easily print one of the directory (in case there are more than one) using own filter
The location should be (in Linux systems):
home//anaconda3/envs//lib/python/site-packages/ I installed miniconda and found all the installed packages in /miniconda3/pkgs
The Conda package cache is not the same as the Python’s site-packages . You shouldn’t mess with these, otherwise you’ll could end up with corruption complaints from Conda.
You could also type ‘conda list’ in a command line. This will print out the installed modules with the version numbers. The path within your file structure will be printed at the top of this list.
conda list, just gave me » packages in environment at /Users/user/anaconda:» as output. The exact location for the packages was required, which is /Users/user/anaconda/lib/python2.7/’.
‘conda list’ is a very good idea when you want to know from which repository a package was installed. It also shows an installation via pip. So this is a really good tip although it does not answer the question.
This answer actually works for me — not sure why it’s downvoted! conda list , as its first line, spits out the root of your conda installation; inside that is the pkgs folder.
. actually (re. my preceding comment), inside the root of the miniconda installation I find some packages at ‘lib/python3.7/site-packages’
You should find installed packages in :
anaconda’s directory / lib / site_packages
Generic approach for environment foo from Conda CLI would be:
conda run -n foo python -m site which for my base environment looks like:
$ conda run -n base python -m site sys.path = [ '/Users/mfansler/miniconda3/lib/python3.8', '/Users/mfansler/miniconda3/lib/python38.zip', '/Users/mfansler/miniconda3/lib/python3.8/lib-dynload', '/Users/mfansler/miniconda3/lib/python3.8/site-packages', ] USER_BASE: '/Users/mfansler/.local' (exists) USER_SITE: '/Users/mfansler/.local/lib/python3.8/site-packages' (doesn't exist) ENABLE_USER_SITE: True The answer is the site-packages in the sys.path list.
PEP 370 – Per user site-packages directory
This PEP proposes a new a per user site-packages directory to allow users the local installation of Python packages in their home directory.
Rationale
Current Python versions don’t have a unified way to install packages into the home directory of a user (except for Mac Framework builds). Users are either forced to ask the system administrator to install or update a package for them or to use one of the many workarounds like Virtual Python [1], Working Env [2] or Virtual Env [3].
It’s not the goal of the PEP to replace the tools or to implement isolated installations of Python. It only implements the most common use case of an additional site-packages directory for each user.
The feature can’t be implemented using the environment variable PYTHONPATH. The env var just inserts a new directory to the beginning of sys.path but it doesn’t parse the pth files in the directory. A full blown site-packages path is required for several applications and Python eggs.
Specification
site directory (site-packages)
A directory in sys.path . In contrast to ordinary directories the pth files in the directory are processed, too.
A site directory inside the users’ home directory. A user site directory is specific to a Python version. The path contains the version number (major and minor only). Unix (including Mac OS X) ~/.local/lib/python2.6/site-packages Windows %APPDATA%/Python/Python26/site-packages
Usually the parent directory of the user site directory. It’s meant for Python version specific data like config files, docs, images and translations. Unix (including Mac) ~/.local/lib/python2.6 Windows %APPDATA%/Python/Python26
It’s located inside the user’s home directory. The user site and use config directory are inside the base directory. On some systems the directory may be shared with 3rd party apps. Unix (including Mac) ~/.local Windows %APPDATA%/Python
A directory for binaries and scripts. [10] It’s shared across Python versions and the destination directory for scripts. Unix (including Mac) ~/.local/bin Windows %APPDATA%/Python/Scripts
Windows Notes
On Windows the Application Data directory (aka APPDATA ) was chosen because it is the most designated place for application data. Microsoft recommends that software doesn’t write to USERPROFILE [5] and My Documents is not suited for application data, either. [8] The code doesn’t query the Win32 API, instead it uses the environment variable %APPDATA%.
The application data directory is part of the roaming profile. In networks with domain logins the application data may be copied from and to the a central server. This can slow down log-in and log-off. Users can keep the data on the server by e.g. setting PYTHONUSERBASE to the value “%HOMEDRIVE%%HOMEPATH%Applicata Data”. Users should consult their local administrator for more information. [13]
Unix Notes
On Unix ~/.local was chosen in favor over ~/.python because the directory is already used by several other programs in analogy to /usr/local . [7] [11]
Mac OS X Notes
On Mac OS X Python uses ~/.local directory as well. [12] Framework builds of Python include ~/Library/Python/2.6/site-packages as an additional search path.
Implementation
The site module gets a new method adduserpackage() which adds the appropriate directory to the search path. The directory is not added if it doesn’t exist when Python is started. However the location of the user site directory and user base directory is stored in an internal variable for distutils.
The user site directory is added before the system site directories but after Python’s search paths and PYTHONPATH . This setup allows the user to install a different version of a package than the system administrator but it prevents the user from accidentally overwriting a stdlib module. Stdlib modules can still be overwritten with PYTHONPATH .
For security reasons the user site directory is not added to sys.path when the effective user id or group id is not equal to the process uid / gid [9]. It’s an additional barrier against code injection into suid apps. However Python suid scripts must always use the -E and -s option or users can sneak in their own code.
The user site directory can be suppressed with a new option -s or the environment variable PYTHONNOUSERSITE . The feature can be disabled globally by setting site.ENABLE_USER_SITE to the value False . It must be set by editing site.py . It can’t be altered in sitecustomize.py or later.
The path to the user base directory can be overwritten with the environment variable PYTHONUSERBASE . The default location is used when PYTHONUSERBASE is not set or empty.
distutils.command.install (setup.py install) gets a new argument —user to install packages in the user site directory. The required directories are created on demand.
distutils.command.build_ext (setup.py build_ext) gets a new argument —user which adds the include/ and lib/ directories in the user base directory to the search paths for header files and libraries. It also adds the lib/ directory to rpath.
The site module gets two arguments —user-base and —user-site to print the path to the user base or user site directory to the standard output. The feature is intended for scripting, e.g. ./configure —prefix $(python2.5 -m site —user-base)
distutils.sysconfig will get methods to access the private variables of site. (not yet implemented)
The Windows updater needs to be updated, too. It should create a menu item which opens the user site directory in a new explorer windows.
Backwards Compatibility
Reference Implementation
A reference implementation is available in the bug tracker. [4]