Tutorial :Is site-packages appropriate for applications or just libraries?


I'm in a bit of a discussion with some other developers on an open source project. I'm new to python but it seems to me that site-packages is meant for libraries and not end user applications. Is that true or is site-packages an appropriate place to install an application meant to be run by an end user?


Once you get to the point where your application is ready for distribution, package it up for your favorite distributions/OSes in a way that puts your library code in site-packages and executable scripts on the system path.

Until then (i.e. for all development work), don't do any of the above: save yourself major headaches and use zc.buildout or virtualenv to keep your development code (and, if you like, its dependencies as well) isolated from the rest of the system.


We do it like this.

Most stuff we download is in site-packages. They come from pypi or Source Forge or some other external source; they are easy to rebuild; they're highly reused; they don't change much.

Must stuff we write is in other locations (usually under /opt, or c:\opt) AND is included in the PYTHONPATH.

There's no great reason for keeping our stuff out of site-packages. However, our feeble excuse is that our stuff changes a lot. Pretty much constantly. To reinstall in site-packages every time we think we have something better is a bit of a pain.

Since we're testing out of our working directories or SVN checkout directories, our test environments make heavy use of PYTHONPATH.

The development use of PYTHONPATH bled over into production. We use a setup.py for production installs, but install to an alternate home under /opt and set the PYTHONPATH to include /opt/ourapp-1.1.


The program run by the end user is usually somewhere in their path, with most of the code in the module directory, which is often in site-packages.

Many python programs will have a small script located in the path, which imports the module, and calls a "main" method to run the program. This allows the programmer to do some upfront checks, and possibly modify sys.path if needed to find the needed module. This can also speed up load time on larger programs, because only files that are imported will be run from bytecode.


Site-packages is for libraries, definitely.

A hybrid approach might work: you can install the libraries required by your application in site-packages and then install the main module elsewhere.


If you can turn part of the application to a library and provide an API, then site-packages is a good place for it. This is actually how many python applications do it.

But from user or administrator point of view that isn't actually the problem. The problem is how we can manage the installed stuff. After I have installed it, how can I upgrade and uninstall it?

I use Fedora. If I use the python that came with it, I don't like installing things to site-packages outside the RPM system. In some cases I have built rpm myself to install it.

If I build my own python outside RPM, then I naturally want to use python's mechanisms to manage it.

Third way is to use something like easy_install to install such thing for example as a user to home directory.


  • Allow packaging to distributions.
  • Allow selecting the python to use.
  • Allow using python installed by distribution where you don't have permissions to site-packages.
  • Allow using python installed outside distribution where you can use site-packages.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »