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?
+3
A:
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.
JimB
2009-04-24 18:58:55
+3
A:
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.
S.Lott
2009-04-24 19:18:15
Sounds like you guys could really benefit from virtualenv+pip (or zc.buildout).
Carl Meyer
2009-04-27 12:00:01
We don't have any problems with out configuration -- virtualenv doesn't add much value. We use some kind of VM (VMWare perhaps -- someone else is responsible for that) to host the various servers for test, QA, production, etc. Using many virtual machines seems simpler than virtualenv on a single machine.
S.Lott
2009-04-27 12:31:42
Of course, if you have the hardware to run a separate VM for each project you work on, then Python-level virtualization isn't necessary. How do you do development, though? Does every developer run a local VMWare instance for each project?
Carl Meyer
2009-04-27 20:36:08
It's Django. We develop on Windows but deploy in VM's Red Hat. There a few places (3 or 4) where we need to know if the platform is "win32" and then only to determine whether or not to use a shell with subprocess.Popen.
S.Lott
2009-04-27 20:48:29
A:
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.
Seun Osewa
2009-04-24 19:19:54
A:
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.
So
- 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.
iny
2009-04-25 04:54:16
+3
A:
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.
Carl Meyer
2009-04-27 11:58:15
Great answers all. Thanks. Most of the answers were a variation on this but I believe the first paragraph of this answer answers the question the most concisely. For this application the codes already being distributed so it's probably past time to try zc.buildout or virtualenv but I'll keep them in mind in the future.
AaronS
2009-04-27 20:08:37