Macports sets up the ownership of its Python site-packages directory as root.wheel with world-readable permissions. Python packages instally via port install have the same

# ls -l -d /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages
drwxr-xr-x  151 root  wheel  5134 Mar  8 10:56 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages

This of course prevents individual users from using pip install to add packages, which is just fine since that really ought to be done as root.

However, if one uses sudo or a root shell to pip install, the packages are installed by pip as readable only by root.wheel (740).

% sudo pip install BeautifulSoup
% ls -l -d   /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/BeautifulSoup.py
-rw-r-----  1 root  wheel  79567 Mar  8 11:09 /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/BeautifulSoup.py

This precludes my user account from actually importing or using the package (*).

How can I get pip to always put reasonable permissions on installed packages?

Update (edit)

I have reworded the question to emphasize that it is about pip installs only. I would also like to emphasize here that the problem is not about needing write permission to the modules. The problem is that the modules are being installed without read permissions.

(*) A hack to fix it is to chmod a+rX the proper permissions (744/755) onto the newly installed package files

Update 2 (solution)

As suggested by both Mark and Ian, and confirmed in a quick test, this has to do with the umask for root. Here is the documentation on how to change /etc/sudoers for OSX. Note that it is not necessarily a good idea to change the umask for all sudo instances!

  • The permissions you see are correct and reasonable. If you install to anywhere but your home directory (e/g/ /opt) then the files are for more than one user and so should not be writeable by normal users. For individual users they should set up virtualenv and install into their virtualenvs
    – mmmmmm
    Commented Mar 8, 2015 at 16:26
  • @Mark: If those permissions are both correct and reasonable, then why do you think they differ from the permissions on packages installed via port install?
    – Brian B
    Commented Mar 9, 2015 at 13:33
  • Sorry I missed that - I would still use virtualenv and only install in Macports directory packages installed by Macports and not pip
    – mmmmmm
    Commented Mar 9, 2015 at 13:42
  • Is this simply the umask setting so only readable by user and group and not all (i.e. 022 ) see this SO question
    – mmmmmm
    Commented Mar 9, 2015 at 21:30
  • I was starting to wonder that about the umask, too, so I will be checking tonight.
    – Brian B
    Commented Mar 9, 2015 at 21:40

1 Answer 1


You can use virtualenv to create a local "copy" of the Python installation that's owned and easily manipulated by you. The advantage to using virtualenv is you can make many copies of the same version of Python, but with different versions of similar packages installed, and then switch between them with the virtualenv command line.

This lets you use different versions of libraries in different projects or incompatible libraries.

To install virtualenv:

sudo pip install virtualenv

And now you can use it yourself, without sudo, to create a virtual python owned by you:

mkdir -p ~/Development/mypythonproject
cd ~/Development/mypythonproject
virtualenv .venv
source .venv/bin/activate

For example:

IanCsiMac:~/Development/keybase-python |ruby-2.1.2| [git::develop]
> which python

IanCsiMac:~/Development/keybase-python |ruby-2.1.2| [git::develop]
> source .venv/bin/activate

IanCsiMac:~/Development/keybase-python |ruby-2.1.2| [git::develop]
> which python

IanCsiMac:~/Development/keybase-python |ruby-2.1.2| [git::develop]
> deactivate

IanCsiMac:~/Development/keybase-python |ruby-2.1.2| [git::develop]
> which python

You can virtualenv-install in your ~ directory if you want a default python that you control to be available at all times like so:

cd ~
virtualenv venv

And now you've got ~/venv/bin/pip available to you. You can modify your ~/.bash_profile and add:

source venv/bin/activate

Right at the end of it to have your virtualenv available by default in your shell.

  • I agree virtualenv is nice (or Continuum Analytics' conda even more), but that's really answering a different question. In addition, I rather doubt virtualenv can work properly when the packages in question are not readable. I'll check on that.
    – Brian B
    Commented Mar 9, 2015 at 13:45
  • I just tested on Debian Linux (OSX machine is not to hand)-- virtualenv creates a raw environment without any of the installed packages, so the permissions issue does not arise. Thus, one gets to try and install scipy, numpy etc. manually. (conda is a little friendlier about this sort of thing)
    – Brian B
    Commented Mar 9, 2015 at 14:12
  • @BrianB virtualenv works just fine if the packages are read-only. Yes, if you need packages that are backed by C-compiled libraries you can try conda (which, under the hood, uses virtualenv itself).
    – Ian C.
    Commented Mar 9, 2015 at 14:31
  • that' is kind of my point. These packages are being installed by pip with no read permissions whatsoever. As you say, read-only would be fine! (I think a lot of people are misreading the original question, and believing that I am asking about write permissions, so I will change the emphasis).
    – Brian B
    Commented Mar 9, 2015 at 20:33
  • @BrianB I got what you were saying. It's an unfortunate side effect of using sudo. You could change the umask for root temporarily when you call sudo pip ... so it doesn't happen, but you really want to remember to change it back when you're done.
    – Ian C.
    Commented Mar 9, 2015 at 20:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .