1
shitiven 2012-07-19 11:07:53 +08:00
貌似给搞复杂了哇,我们做法是把django的src直接仍在project的根目录下,如果是python版本不一样的话,就export 修改下pythonpath就好了
|
4
shiny 2012-07-19 12:21:00 +08:00
Virtualenv + uwsgi + nginx,非常好用
|
5
shitiven 2012-07-19 12:49:31 +08:00
@ratazzi 我说的是我这边的做法,就把所有的库都放到了项目下面的Library目录下,然后把路径加到pythonpath中,没有把库都global了,因为现在大多数开源库都放在github上了,所以有更新的时候就直接git pull 拉一下就好了。。 可能每个团队开发习惯不一样吧
|
6
accesine 2012-07-19 13:05:47 +08:00
最简单的一个问题:
Virtualenv 如何 和 某个版本的 Python 关联起来的呢? 比如: 我需要: mkvirtualenv product # 使用 python version 2.7 mkvirtualenv dev # 使用 python version 3.2 如何做到呢? source /usr/local/bin/virtualenvwrapper.sh 你的 virtualenvwrapper.sh 里面是什么东东? 请帮助,多谢。 |
7
rexren 2012-07-19 15:42:59 +08:00 1
|
9
reorx 2012-07-19 17:24:09 +08:00
既然都使用 virtualenv 了,为何不自己编译安装 Python,再在其上安装 virtualenv 呢,这样 Python 环境就真正不受任何外界因素(包括系统对某些 Python 库的依赖)的影响了。
|
10
cheka OP @shitiven
直接把依赖代码塞项目目录下有不少弊病,譬如: 1. 项目目录下会有很多第三方代码库,譬如我们项目依赖近80个第三方库; 2. 工作环境复制会依赖文件拷贝,但是到了每个人手上,这些依赖就不好控制,有人会升级到最新版本,有人会用其他fork的版本,导致一旦出现问题难以查找; 另外,用virtualenv+uwsgi+nginx 还有额外好处,譬如同一台机器上可以建立几个virtualenv,里面可以有不同的依赖甚至代码分支,响应不同的端口号,这样一台机器就能同时提供生产环境和测试环境,在没有足够物理服务器或者不想折腾虚拟机的情况下,是个比较简单的方案。 |
11
shitiven 2012-07-19 18:07:38 +08:00
@cheka 是的,库多了就比较麻烦,所以最近在改进,正在写个脚本模拟npm install(nodejs)类似的安装方式,开发人员有需要的库只要改下配置文件就好,然后执行一个脚本安装就好,类库是不提交到代码内的.... 这样项目在任何环境移植类库都可以一键下载...
virtualenv我们也试着看看,看着也挺好玩的 |
14
alswl 2012-07-20 22:39:22 +08:00 1
扇贝啊,哈哈,又看到了,感谢分享。
virtualenv + virtualenvwrapper 神奇啊。 在 $HOME/.virtualenv/ 自动管理多个环境,使用 workon 命令即可轻松切换。 类似于 bundle + rvm。 |