我在开源项目上与其他一些开发人员进行了一些讨论。我是python的新手，但在我看来，site-packages适用于库而不是最终用户应用程序。这是真的还是site-packages适合安装应由最终用户运行的应用程序？
答案 0 :(得分：4)
我们这样做。
我们下载的大多数内容都是在网站包中。他们来自pypi或Source Forge或其他一些外部来源;它们很容易重建;它们被高度重用;他们的变化不大。
我们写的内容必须在其他位置（通常位于/opt或c:\opt下）并且包含在PYTHONPATH中。
没有很好的理由让我们的东西远离site-packages。然而，我们的微弱借口是我们的东西变化很大。几乎不断。每当我们认为我们有更好的东西时，重新安装在网站包中会有点痛苦。
由于我们正在测试我们的工作目录或SVN结帐目录，因此我们的测试环境会大量使用PYTHONPATH。
PYTHONPATH的开发使用已经渗透到生产中。我们使用setup.py进行生产安装，但安装到/opt下的备用主目录，并将PYTHONPATH设置为包含/opt/ourapp-1.1。
答案 1 :(得分：4)
一旦你准备好分发你的应用程序，就可以将你的库代码放在系统路径中的站点包和可执行脚本中，将它打包成你喜欢的发行版/操作系统。
在此之前（即所有开发工作），不要做以上任何事情：保存自己的主要问题并使用zc.buildout或virtualenv来保留您的开发代码（如果您愿意的话） ，它的依赖性也与系统的其他部分隔离开来。
答案 2 :(得分：3)
最终用户运行的程序通常位于其路径中的某个位置，模块目录中的大部分代码通常位于站点包中。
许多python程序将在路径中放置一个小脚本，用于导入模块，并调用“main”方法来运行程序。这允许程序员进行一些前期检查，并且如果需要可能修改sys.path以找到所需的模块。这也可以加快较大程序的加载时间，因为只有导入的文件才能从字节码运行。
答案 3 :(得分：0)
Site-packages绝对适用于库。
混合方法可能有效：您可以在站点包中安装应用程序所需的库，然后将主模块安装在其他位置。
答案 4 :(得分：0)
如果您可以将部分应用程序转换为库并提供API，那么site-packages就是一个很好的选择。这实际上有多少python应用程序可以做到这一点。
但是从用户或管理员的角度来看，实际上并不是问题所在。问题是我们如何管理已安装的东西。安装后，如何升级和卸载？
我使用Fedora。如果我使用它附带的python，我不喜欢在RPM系统之外的站点包中安装东西。在某些情况下，我自己构建了rpm来安装它。
如果我在RPM之外构建自己的python，那么我自然希望使用python的机制来管理它。
第三种方法是使用类似easy_install的东西来安装这样的东西，例如作为用户到主目录。
所以