An AdminSite offer interfaces to manage databases. It includes traditional authentications, permissions, data display and POST saving mechanisms, etc. , which are nasty trifles if you try implement them from scratch using bottle or other things.

Now I can build a decent system in about 100 lines code, after many many document reading and code digging, I want to share the story how I solve the problem encountered while implementing the "Leave password blank if don't want to change it" requirement. As commonly seen in other applications when user try to update their profile.

Firstly the background. My data Model:

1
2
3
4
5

class Users(Model):
    account = models.CharField(max_length=128, unique = True)
    password = models.CharField(db_column = 'crypt',max_length=384, blank=True)
    name = models.CharField(max_length=768)
    #...

The password is stored hashed in the DB crypt column. If I just let the AdminSite pickup things like that, it just show the password value in the plain input text.

Firstly I tell django to show it as a password input widget.

1
2
3
4
5
6
7
8

class MailUsersForm(forms.ModelForm):
    class Meta:
        model = Users
        widgets = {
                'password': forms.PasswordInput(render_value = False),
        }
class MailUsersAdmin(admin.ModelAdmin):
    form = MailUsersForm

Ah, overriding the form in the ModelAdmin does the trick.

Now in the edit page, the Password field shows an empty input widget.

Now I need to hash the password before commit to the DB. I found the save_model method.

1
2
3
4
5
6
7

class MailUsersAdmin(admin.ModelAdmin):
    # ...
    def save_model(self, request, obj, form, change):
        new_psw = request.POST["password"]
        if len(new_psw):
            obj.password = obj._hash_password()
            obj.save()

This works, but buggy. The password field is defaultly blank. It will clean the field in the DB without processing. The problem is, by the time in the save_model method is triggered, the obj is already updated by the values from the POST request. There's no way to get the old password value here. All I can do without changing the old password, is to skip the obj.save(). But what if I only want to update other things?

Through out the documents, I found some other places to approch the Model instance.

Firstly the django.forms.ModelForm.save method. The module instance is returned from this method (then passed to the save_model), so I inspect the object with ipdb to see if the data is updated here:

1
2
3
4
5
6

class MailUsersForm(forms.ModelForm):
 
    def save(self, *args, **kw):
        import ipdb; ipdb.set_trace()
        obj = super(MailUsersForm, self).save(*args, **kw)
        return obj

Unfortunately Yes. The instanced obj from the derived save is already updated to the POST value.

And django signals, pre_save, all the same way. (The signal thing is even emmited after the forms.ModelForm.save)

Googled around and nothing suitble, I decided to find the right way myself.

There must be somewhere in django codes that sets the attributes with values from the POST requsts. So I add a hook in the Model.

1
2
3
4
5
6
7
8

class Users(Model):
    #....
    def __setattr__(self, name, value):
        if name == "password":
            if self.id == 370:
                import ipdb; ipdb.set_trace()
 
        return Model.__setattr__(self, name, value)

The if self.id thing is for filtering the specific page I submit the save in the browser. Now ipdb let me in debug mode.

ipdb> w
 
#................. Many Many unrelated things
 
  /usr/lib/python2.7/site-packages/django/forms/forms.py(272)full_clean()
    270         self._clean_fields()
    271         self._clean_form()
--> 272         self._post_clean()
    273         if self._errors:
    274             del self.cleaned_data
 
  /usr/lib/python2.7/site-packages/django/forms/models.py(309)_post_clean()
    307         opts = self._meta
    308         # Update the model instance with self.cleaned_data.
 
--> 309         self.instance = construct_instance(self, self.instance, opts.fields, opts.exclude)
    310
    311         exclude = self._get_validation_exclusions()
 
  /usr/lib/python2.7/site-packages/django/forms/models.py(51)construct_instance()
     49             file_field_list.append(f)
     50         else:
---> 51             f.save_form_data(instance, cleaned_data[f.name])
     52
     53     for f in file_field_list:
 
  /usr/lib/python2.7/site-packages/django/db/models/fields/__init__.py(454)save_form_data()
    452
    453     def save_form_data(self, instance, data):
--> 454         setattr(instance, self.name, data)
#---------------^ this matters!
    455
    456     def formfield(self, form_class=forms.CharField, **kwargs):
 
> /home/boypt/Projects/maildbadmin/maildbadmin/models.py(55)__setattr__()
     53             if self.id == 370:
     54                 import ipdb; ipdb.set_trace()
---> 55                 print "set :", value
     56 #
     57 #

From the call stack, the setattr call to the Model changes the data. I check django/db/models/fields/__init__.py source, find that this is a Field base class, so the obvious solution is to override this method.

1
2
3
4
5
6
7
8
9
10
11

class PasswordCharField(models.CharField):
    def save_form_data(self, instance, data):
        if data != u'':
            data = instance._hashed_pwd(data)
            setattr(instance, self.name, data)
 
class Users(Model):
    #...
    password = PasswordCharField(db_column = 'crypt', max_length=384, blank=True)
 
    #.....

OK, now everything's done here. The save_model overriding is no more needed, for the Model instance's password will not be set to empty at all when the user left the field blank when they submit.

安装：

Ubuntu

添加ppa，安装。 目前只有Lucid, Maverick, Natty几个版本还需要添加，以后版本都在官方原，直接apt-get install即可。

1
2
3

add-apt-repository ppa:uwsgi/release
apt-get update
apt-get install uwsgi-python

Debian

目前Debian sid已经收录了uwsgi，一般服务器安装的testing/stable，只能自己修改apt的配置，从sid里面port过来。

注意：以下操作可能毁掉您的整个debian包系统。以下命令仅在Debian wheezy，即目前的testing运行测试安装过，如果你的是squeeze，自己修改01all那里 Pin: release a=squeeze 一行，但不保证能够正常运行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

echo "deb http://ftp.tw.debian.org/debian sid main non-free contrib" >> /etc/apt/sources.list
cat > /etc/apt/preferences.d/01all << EOF
Package: *
Pin: release a=testing
Pin-Priority: 1000
EOF
 
cat > /etc/apt/preferences.d/02uwsgi << EOF
Package: uwsgi
Pin: release a=sid
Pin-Priority: 1010
EOF
 
apt-get update
apt-get install uwsgi uwsgi-core uwsgi-plugin-python

Centos, RHEL, Fedora, ...

You're on your own, linux user.

配置

常见配置文件：

1
2
3
4
5
6
7
8
9
10
11

cat > /etc/uwsgi/apps-enabled/test.ini << EOF
[uwsgi]
chmod-socket = 666
limit-as = 256
processes = 6
max-request = 2000
memory-report = true
enable-threads = true
virtualenv = /somewhere/to/your/virtualenv
wsgi-file = /home/somewhere/app.py
EOF

用ini方式的配置是比xml的容易写多了。具体配置说明请看Doc

默认的sock文件在/var/run/uwsgi/test/socket

配合nginx使用的配置文件：

1
2
3
4
5
6
7
8
9
10

cat > /etc/nginx/sites-enabled/test << EOF
server {
        listen   80;
        server_name host.domain.com;
        location / {
                include uwsgi_params;
                uwsgi_pass unix:///var/run/uwsgi/test/socket;
        }
}
EOF

切换Python版本

系统中可能安装有多个版本的Python，又或者同个系统里面有的app跑python3, 有的跑python2.6 stackless, 有的跑python2.7...

uwsgi 是通过plugin的方式加载不同的python解析器的，debian的uwsgi-plugin-python包里面提供了python26_plugin.so, python27_plugin.so, 不过uwsgi如果在app配置里面没有plugins参数指定使用哪个时候，会尝试加载/usr/lib/uwsgi/plugins/python_plugin.so，这个文件在debian下是个链接文件，可以运行update-alternatives --config uwsgi-plugin-python命令来修改这个默认版本。

源里面没有提供stackless python的plugin，只能自己编译了，还好非常简单：

/path/to/your/stackless/python uwsgiconfig.py --plugin plugins/stackless

然后把生成的python_stackless.so放到/usr/lib/uwsgi/plugins 就能被uwsgi加载了。

其他plugin的编译基本都这样，看源代码里面的plugins目录。

代码

使用uwsgi运行代码的时候，可以import uwsgi模块，和uwsgi进行一定的交互。

uwsgi 的源代码包当中有个uwsgidecorators.py，提供了多数的uwsgi接口，描述文档在此。以下是几个典型应用。

自动重载

好一些web框架都有检测修改了源文件就自动重新加载的功能，但是在uwsgi里面这个方法是不好用了。

Django

加入以下代码：

1
2
3
4
5
6
7
8

import uwsgi
from uwsgidecorators import timer
from django.utils import autoreload
 
@timer(3)
def change_code_gracefull_reload(sig):
    if autoreload.code_changed():
        uwsgi.reload()

Bottle

Bottle 的reload是它内置基础web服务器的功能，在uwsgi里面只能自己写代码监控。

想要简单很难做到完美：

1
2
3
4
5
6
7

from uwsgidecorators import filemon
 
filemon('/tmp/foo')(uwsgi.reload)
filemon('/tmp/foo2')(uwsgi.reload)
filemon('/tmp/foo3')(uwsgi.reload)
filemon('/tmp/foo4')(uwsgi.reload)
filemon('/tmp/foo5')(uwsgi.reload)

于是这些文件出现修改的时候，就自动reload。其实你可以自己加入调用uwsgi.reload()的响应。

pylons, web.py, cherrypy ..

程序员自己研究去。

threading

原来使用内置线程做的异步程序会发现在uwsgi，里面的线程好像都没启动了、数据库没有连接了……原因是uwsgi加载了代码后，fork出多个子进程，子进程里面的线程如果没有被再度激活，是不工作的。

有两个方法，一是在这个app的配置里面加上：

lazy = true

这样代码会在子进程fork了之后才开始加载。

二是使用uwsgi模块的api，uwsgidecorators 里面有相应的装饰器，这样uwsgi会在fork之后自动调用你要重新启动的线程。

1
2
3
4
5
6
7
8
9
10
11
12
13

from uwsgidecorators import postfork
 
@postfork
def reconnect_to_db():
    myfoodb.connect()
 
@postfork
def restart_threads():
    global thread1, thread2
    thread1 = MyThread1()
    thread1.start()
    thread2 = MyThread2()
    thread2.start()

监控

虽然uwsgi 默认带了SNMP功能，可以给外部监控其运行情况，但uwsgi的源码包里面带了个uwsgistatus.py文件，里面简单的提供了读取uwsgi模块的属性形成的报告。 可以把里面的代码copy到app项目里面，作为一个简单的监控数据。

Reference

以上部分代码取自uWSGI Wiki页面

• Doc
• Example
• TipsAndTricks

在Python里面，如果你使用上Qt，SQLAlchemy，Twisted之类各种大型类库时候，有时候多重继承Multiple Inheritance是个简单的解决方法，但是多重继承的复杂性总容易造成误解和疑惑。

一般“常识”说，使用super访问父类的属性/方法，这种说法在多重继承里面是不成立的，多重继承的类并没有父类的概念(There is no superclass in a MI world)。类似的博客在过去几年被人写了无数遍了，因为过去版本里面python官方文档对super的解释非常有限而且有误导解释，直到2.6以后的文档，才详细说明了super在单继承和多继承的两种不同工作方式。当时苦逼的程序员甚至不得不去翻看Python源码才搞清楚是什么回事。以致几年来很多人对python的多重继承保持怀疑态度。

Python多重继承使用Method Resolution Order的动态算法来解决一个方法名的调用顺序，mro其实说来简单，就是一个深度优先的继承列表，很易理解，但随之来的是遇到互不相同的构造器__init__参数的问题。

Codepad运行结果：http://codepad.org/qQNiMzBl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class A(object):
    def __init__(self, arg1):
        print "init func in A, with arg1 '%s'" % arg1
        super(A, self).__init__()
 
class B(object):
    def __init__(self, arg1, arg2):
        print "init func in B, with arg1'%s', arg2 '%s'" % (arg1, arg2)
        super(B, self).__init__(arg1)
 
class C(B, A):
    def __init__(self, arg1, arg2):
        print "init func in C, with arg1'%s', arg2 '%s'" % (arg1, arg2)
        super(C, self).__init__(arg1, arg2)
        print C.__mro__
 
c = C("C's arg1", "C's arg2")

执行结果：

init func in C, with arg1'C's arg1', arg2 'C's arg2'
init func in B, with arg1'C's arg1', arg2 'C's arg2'
init func in A, with arg1 'C's arg1'
(<class '__main__.C'>, <class '__main__.B'>, <class '__main__.A'>, <type 'object'>)

可见几个类的构造器的执行顺序正是mro列表的顺序。重点是多重继承的各个类的构造器__init__之所以能够执行，是因为每个构造器里面都有一句super()，这个super完成mro列表中下一个类的构造器的调用。

这个事实听起来似乎很自然，但看代码，B的构造器还得必须知道A的构造器的参数？B需要知道自己将会被C同时继承A，并且调用A的构造？！！很荒谬，但不幸的这是mro的特点。代码是可以这么写，但不应该，为另一个不知道什么时候会被一起继承的类特地地写代码，跟面对对象设计的解耦原则相违背。

How

在mro方式的基础上，这个问题是不可能有效解决的，只能避免。概括起来大概有这么 两种方式。

1.使用传统类的方式，显式调用被继承类的构造器，避开super的mro自动化工作。

Codepad 看运行效果： http://codepad.org/XCVdKCPm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class A(object):
    def __init__(self, arg1):
        print "init func in A, with arg1 '%s'" % arg1
 
class B(object):
    def __init__(self, arg1, arg2):
        print "init func in B, with arg1'%s', arg2 '%s'" % (arg1, arg2)
 
class C(A, B):
    def __init__(self, arg1, arg2):
        print "init func in C, with arg1'%s', arg2 '%s'" % (arg1, arg2)
        #super(C, self).__init__(arg1) #这两行
        A.__init__(self, arg1)       #等价
        B.__init__(self, arg1, arg2)
        print C.__mro__
 
c = C("C's arg1", "C's arg2")

注意 C继承A，B的顺序已经改变。

要排除一个容易产生的误解。Python文档里面的super有个很显著的Note：super() only works for new-style classes. super只适用于新类。但新类并不必须使用super。

直接调用被继承类的__init__作为unbound方法调用，需要指定一个实例，如self作为参数，依次调用各个被继承类。缺点是若果这几个被继承类也在构造方法里面使用这样调用了同一个上级被继承类，会出现“爷爷类”的构造方法被调用多次的情况。

如果一定使用super，要注意继承列表的顺序。super(TYPE, self).method调用的是mro列表中第一个，也即继承列表第一个类的方法。

PyQt里面的类内部一般（未细究）都使用__init__的方式来初始化代码，因而很多PyQt的例子代码都是使用QtGui.QMainWindow.__init__(self)这样的代码来初始化。当然在单继承时候和super的写法是等价的，但最好使用统一的原则:

一个简单好记的原则：

• 如果"被继承类"都使用__init__，"继承类"就使用__init__来初始化；
• 如果"被继承类"都使用super，"继承类"就使用super来初始化；

2.使用Composition / Association Pattern的设计模式（即'Is-A'转换成'Has-A'）来实现相同功能，避免多重继承。

这个方法听起来未免有点让人不快（破坏了原有设计思维），但实际上很可能这是更好的方式，更清晰的代码，尤其是要继承的类里面混合了使用super，__init__两种初始化方式的时候。

Reference

• Python: Correct way to initialize when superclasses accept different arguments?
• Things to Know About Python Super 2 3
• 关于Python的super用法研究
• Python Built-in Functions#super()

目前的前端技术中，能够实现跨域POST的成熟方案一般只有借助flash，这也是Uploadify的特点吧。

Uploadify的官方提供的是一个php的后端，后端需要做的事情相当简单，就是把POST的临时数据存放到指定路径。 有不少中文资料是把uploadify作为.net程序的上传控件，原理其实一样，所以用Python实现也是很简单的。

其实那些实现的后端（包括官方实现的php）都有安全性问题，比如限制文件类型、指定上传路径都可以在远端控制，上传个木马之类会导致服务器被入侵。当然这是因为他们提供的例子是半成品，实际使用起码应该加上session id的验证之类，因为上传时候数据是由Flash发出的，和浏览器的Session无关。

下面的Python例子中，则就如还在beta阶段的uploadify 3的开发日志讨论的，暂时忽略掉folder参数。

完整的例子代码可在我的仓库下载。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

import bottle
bottle.debug(True)
from bottle import run, route, request, get, view, static_file, abort
import shutil
import os
 
UPLOAD_BASE = "/tmp/upload"
ALLOWED_TYPE = ("wmv","rmvb","mpeg","3gp","avi","mov","mp4","flv","mpg","vob","png","jpg")
 
@route('/upload', method='POST')
def do_upload():
    try:
        filename = request.POST.get('Filename')
        root, ext = os.path.splitext(filename)
        assert ext[1:].lower() in ALLOWED_TYPE, "Invalid file type: " + ext
        if not os.path.isdir(UPLOAD_BASE):
            os.makedirs(UPLOAD_BASE)
        filedata = request.POST.get('Filedata')
        assert filedata is not None, "Invalid Upload data."
        with open(os.path.join(UPLOAD_BASE, filename), 'wb') as f:
            shutil.copyfileobj(filedata.file, f, 8192)
    except AssertionError, e:
        abort(403, str(e))
    else:
        return filename
 
@route('/crossdomain.xml')
def crossdomain():
    return """<cross-domain-policy>
<allow-access-from domain="*"/>
</cross-domain-policy>
"""
 
@route('/static/:path#.+#')
def server_static(path):
    return static_file(path, root='static')
 
@route('/')
@view('upload')
def index():
    return dict()
 
run(host='0.0.0.0', port=8080)

此前有在公司技术部内推广使用trac做项目管理的想法，做过了解，不过因为各种原因还是用不下来。赖勇浩的博客有一系列文章介绍trac，也包括了在公司环境使用的经验。

Trac作为一套web应用，其实部署步骤和此前介绍的MoinMoin, Mercurial很类似的。

以下步骤介绍安装包含多国语言的基本trac环境。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

 
#安装基本组建
sudo -s
add-apt-repository ppa:nginx/stable
add-apt-repository ppa:uwsgi/release
apt-get update
apt-get install nginx uwsgi-python python-virtualenv subversion
 
#本次安装所需的路径，可按需修改
TRAC_ENV_PYHOME="/srv/trac/python-env"
TRAC_PROJECTS_DIR="/srv/trac/projects"
PROJECT_PATH="$TRAC_PROJECTS_DIR/myproject1"
 
#组件配置
cat >/etc/uwsgi-python/apps-enabled/uwsgi.xml << EOF
<uwsgi>
  <limit-as>256</limit-as>
  <processes>6</processes>
  <memory-report/>
  <vhost/>
  <no-site/>
</uwsgi>
EOF
 
#安装Trac， dev版本。
#虽然其实可以easy_install Trac，但是就不会编译多国语言了。
 
cd /tmp
virtualenv $TRAC_ENV_PYHOME
source $TRAC_ENV_PYHOME/bin/activate
easy_install Genshi
easy_install Babel
 
svn co http://svn.edgewall.org/repos/trac/trunk trac
cd trac
python setup.py install
 
#建立项目
mkdir $TRAC_PROJECTS_DIR
trac-admin $PROJECT_PATH initenv
 
#如果你的终端为中文（zh_CN.UTF-8，比如date命令是中文的年月日），现在应该是中文提示，否则以上安装可能问题。
 
#输入项目名称、数据库连接（默认）后，项目建立完成
 
trac-admin $PROJECT_PATH deploy $PROJECT_PATH/deploy
 
cd $PROJECT_PATH/deploy/cgi-bin
cp trac.wsgi trac_wsgi.py
 
chown www-data:www-data -R $PROJECT_PATH
 
cat >/etc/nginx/sites-enabled/trac-project1 << EOF
server {
    listen   80;
    server_name project1.trac.domain.com;
    location / {
                include uwsgi_params;
                uwsgi_pass unix:///var/run/uwsgi-python/uwsgi/socket;
                uwsgi_param UWSGI_PYHOME $TRAC_ENV_PYHOME;
                uwsgi_param UWSGI_CHDIR $PROJECT_PATH/deploy/cgi-bin;
                uwsgi_param UWSGI_SCRIPT trac_wsgi;
                uwsgi_param UWSGI_SCHEME \$scheme;
                uwsgi_param REMOTE_USER \$remote_user;
        }
}
EOF
 
service uwsgi-python restart
service nginx reload

现在打开浏览器，根据你的地址，应该能打开自己的Trac了。

一个Trac实例只管理一个项目，如果需要多个trac就需要重复上述“添加项目”后的步骤。

Tips:

上述trac-admin /xxx deploy命令后，生成的目录里面有个htdocs目录，包含了项目内的静态文件。如果在nginx配置里面加上这样一段：

        location /htdocs/ {
                root $PROJECT_PATH/deploy;
        }

(注意里面的$PROJECT_PATH变量要对应你实际项目的路径)，

然后修改$PROJECT_PATH/conf/trac.ini内htdocs_location =的值为/htdocs/

可以降低静态文件请求对服务器的压力。

最后，多看官方文档。

Vimpress had been updated to 2.x, usage and configurations are now different, read the officle page in vim.org:

http://www.vim.org/scripts/script.php?script_id=3510

Hi guys, glad to know that many of you are having vimpress forked to improved it's power, while i'm also doing the same thing.

I'm working on a version that had been refactored a lot, changes include:

• Commands simplified. No more BlogPageNew/BlogPageSave commands anymore, managing pages are available via the argument to the original BlogNew/BlogList commands, Meta fields shows you what kind of post you're editing.

• Much better Markdown integrated. No more MarkdownXXX commands. You can decide what you edit (Markdown or HTML) in the meta field, when execute BlogSave or BlogPreview, program parse the meta field to got things done.

• More easier editing wordpress in Markdown. Markdown rawtext will automaticly uploads as an attachment file. Updating a post before is complicated, now after you write a post in markdown in vimpress, and then want to do some update, just open the post in Vimpress, it downloads the attachment and show you your original markdown text, when you BlogSave again, the attachment also got updated for further editing.

This version of vimpress is not yet released, for i'm still debuging, i just finished all this features past few days. If any of you got interested, go to my svn:

svn checkout http://ptcoding.googlecode.com/svn/trunk/vimpress-dev

I separated python code from blog.vim to avoid my coding editor got confused about python syntax, i'll combine them together when final release, if you want to try now, got to change the last line about the python file in "blog.vim".

Now this version is now available as beta, you may try it for now:

https://bitbucket.org/pentie/vimrepress/downloads/vimpress_2.1.0beta_r34_179c33a255c7.zip

I would like to hear any advices from you.

By the way, the document attached is not yet updated, the commands list below are "legle" in the new version, you would find them easy to use:

The document attached is now updated, you may refer to it about the new usage, which are all simplified and powerfied, command examples:

• :BlogList - List 30 recent posts.
• :BlogList page - List 30 recent pages.

• :BlogList post 100 - List 100 recent posts.

• :BlogNew post - Write an new post.

• :BlogNew page - Write an new page.

• :BlogSave - Save (defautely published.)

• :BlogSave draft - Save as draft.

• :BlogPreview local - Preview page/post locally in your browser.

• :BlogPreview publish - Same as `:BlogSave publish' with brower opened.

• :BlogOpen 679

• :BlogOpen http://your-first-blog.com/archives/679
• :BlogOpen http://your-second-blog.com/?p=679
• :BlogOpen http://your-third-blog.com/with-your-custom-permalink

如果单独一个hg仓库，直接运行hg serve就已经是在线仓库，用nginx做的http_proxy反向代理就够了，各种功能齐全。但是要host多个hg仓库，需要用hgwebdir。

Ubuntu当中安装的mercurial已经包含了架设仓库所用的程序，包括cgi/fcgi/wcgi的，主接口在/usr/share/doc/mercurial-common/examples下的hgwebdir.(ws|(f)c)gi。虽然其中的wsgi有效的只有三行。

Mercurial官方Wiki上主要介绍了用apache2来跑cgi方式的仓库，但是作为python的程序，wsgi才是最原生的嘛。用Nginx+uwsgi的方式，资源占用、响应效率等，都要比apache + cgi靠谱。

Nginx+uwsgi的方式很普遍，参见本博客之前的MoinMoin 与 Nginx, fastcgi 与 uwsgi 的配置一文。

但是因为uwsgi处于快速开发过程当中，ppa的打包也还不十分成熟，里面的路径跟以前有些不一样了。

add-apt-repository ppa:nginx/stable
add-apt-repository ppa:uwsgi/release
apt-get update
apt-get install nginx uwsgi-python python-virtualenv mercurial
 
mkdir -p /var/www/hgwebdir
virtualenv /var/www/hgwebdir/python-home
 
cat >/var/www/hgwebdir/hgwebdir_wsgi.py << EOF
from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb.hgwebdir_mod import hgwebdir
 
class hgwebdir_with_fixed_staticfile(hgwebdir):
    def __call__(self, env, respond):
        response = super(self.__class__, self).__call__(env, respond)
        return response[0] if isinstance(response, tuple) else response
 
application = hgwebdir_with_fixed_staticfile('/var/www/hgwebdir/hgweb.config')
EOF
 
cat >/var/www/hgwebdir/hgweb.config << EOF
[collections]
/home/hg-repo = /home/hg-repo
 
[web]
style = monoblue
allow_archive = gz, zip, bz2
baseurl = /
push_ssl = true
hidden = false
allow_read = *
allow_push = user1 user2
 
[extensions]
#highlight =
EOF
 
cat >/etc/uwsgi-python/apps-enabled/uwsgi.xml << EOF
<uwsgi>
  <limit-as>256</limit-as>
  <processes>6</processes>
  <memory-report/>
  <vhost/>
  <no-site/>
</uwsgi>
EOF
 
cat >/etc/nginx/sites-enabled/hgwebdir << EOF
server {
    listen   80;
    client_max_body_size 512m;
    server_name hg.mydomian.com;
    location / {
                include uwsgi_params;
                uwsgi_pass unix:///var/run/uwsgi-python/uwsgi/socket;
                uwsgi_param UWSGI_PYHOME /var/www/hgwebdir/python-home;
                uwsgi_param UWSGI_CHDIR /var/www/hgwebdir/;
                uwsgi_param UWSGI_SCRIPT hgwebdir_wsgi;
                uwsgi_param UWSGI_SCHEME \$scheme;
                uwsgi_param REMOTE_USER \$remote_user;
        }
}
EOF
 
mkdir /home/hg-repo
cd /home/hg-repo
hg init example-repo1
hg init example-repo2
chown -R www-data:www-data /home/hg-repo
 
/etc/init.d/nginx restart
/etc/init.d/uwsgi-python restart

所以，/home/hg-repo下的所有仓库(新建的两个空仓库example-repo1/2)都会被hgwebdir列表在目录上，直接使用其地址就可以pull/push了。

注意的是hgweb.config文件里面的配置，push_ssl = true只允许使用https协议的时候push，也就是需要另外配置一个支持https的nginx。这个属于nginx的基本配置，这里不重提了。

对于不公开的仓库，除了HTTPS，还需要用户名密码，只需要配置nginx的basic http auth，上面命令当中的uwsgi_param REMOTE_USER $remote_user一行配置会把http auth的USER通过协议发送到hgweb，完成其认证过程。

其实hgweb的认证仅仅是用户名的匹配，hgweb.config里面的allow_push = user1 user2是全局设定，各个仓库的.hg/hgrc里面的同样的[web]区下也可以定义allow_push/read，即仓库各自的读写权限。

hgweb.config中注释掉的highlight一行，是启动语法高亮插件用的，打开需要先安装python-pygments包，不然会出错。

这个版本的uwsgi程序的log在/var/log/uwsgi-python/uwsgi.log，如果出任何问题，大概看看log的提示按提示去修复即可。

Update: 2011-3-17

原hgwebdir的程序跟wsgi2协议兼容不好，会出现仓库目录的首页里面的静态文件全部无法打开，log里面的信息是invalid WSGI2.0 response size: 1 .。 上述代码中已经修复（见1楼留言。） Thank You, Leonid.

Vimpress had been updated to 2.x, usage and configurations are now different, read the officle page in vim.org:

http://www.vim.org/scripts/script.php?script_id=3510

If you noticed Vimpress before and got more than one wordpress to write, must glad now to know this VimRePressed support multiple configs and swith freely.

The new VimRePressed (Version: 1.2.0) Changes:

      Add: MarkdownPreview command to preiview markdown in browser.
      Add: MarkdownNewPost command to convert a markdown
           written post into html and set to the new post view.
      Add: Move blog configs info to personal .vimrc
      Add: Multiple config is now supported, and with :BlogSwitch
           command added.
      Add: Show which blog your editing at :BlogList view.
      Fix: Running :BlogList in the List view got error.

Now you got to wirte your blog config in your own ~/.vimrc file. (CAREFUL when your share your vim configure with others then. Use a source my_vimpress.vimrc instead. )

let VIMPRESS=[{'username':'user',
              \'password':'pass',
              \'blog_url':'http://your-first-blog.com/'
              \},
              \{'username':'user',
              \'password':'pass',
              \'blog_url':'http://your-second-blog.com/'
              \}]

The syntax looks just like python or json, dictionarys in a list(or array), only that line brake need to write in the vim way.

BlogSwitch command rotate you from the first blog to the last, then the first. If you got confused, BlogList command can show you which one you're connecting to.

Then the Markdown support. I added two command to save my time saving .mkd file then convert them into html then check in a browser, MarkdownPreview command can do this for me. When flawless, the MarkdownNewPost command switch me to the new post view with all thing I write into html, which is ready to publish.

Download: from google code

SVN Version also available:

1

svn checkout http://ptcoding.googlecode.com/svn/trunk/vimpress

http://www.vim.org/scripts/script.php?script_id=3510

WordPress的客户端其实不少，从live writter到scribefire，用户都不少。但是有时候我们只需要一篇博客包含简洁的HTML，这时候这些所见所得编辑器出来的结果都不一定都让人那么满意，经常需要登录到博客后台去编辑源码。

实际上最适合的还是方法还是先用markdown/reStructed/Tex/WikiText之类的语法写成，然后编译成HTML，再发布到博客。

Vim有个vimpress插件可以直接在Vim当中编辑博客，相当适合这个任务。不过由于官方页面上的vimpress已经久无人维护已经不能用了，之前对vimpress的代码做了 一些改写重构，而且得到外国网友的关注 ，而且冠名 VimRepress ，现在正式发布一个VimRepressed的版本。

比起原版的Vimpress，VimRepress有了更友好的错误提示，带了上传图片等的功能，改善了几个命令的可用性：

• BlogList <count> 列表文章，可以用参数定义列出多少篇文章。默认最近30篇。
• BlogNew 新文章命令，会将当前的buffer内容作为文章的内容。
• BlogOpen <id> 打开文章，需要手动输入post id.
• BlogSave <draft|publish> 保存文章，可以保存为草稿、或者直接发布。
• BlogPreview <draft|publish> 预览文章，实际和BlogSave命令相同，之后会打开浏览器窗口预览文章。但如果你是保存成草稿的，还得在浏览器登录才能看到。
• BlogUpload <file> 可上传图片等文件到博客。自动添加链接代码到光标后。
• BlogCode <code type> 代码片段，添加一个<pre>元素的块，对程序博客特别有用，目前默认用wp-syntax插件的高亮模式。

下载: From Google Code

SVN 版本: svn co http://ptcoding.googlecode.com/svn/trunk/vimpress/

安装：

下载以上.zip文件，解压到~/.vim目录:

  cd ~/.vim
  unzip /where/you/downlaod/vimpress-1.x.x.zip

配置：

编辑 ~/.vim/plugin/blog.vim, 查找Settings，将会找到如下的一块代码：

#####################
#      Settings     #
#####################
 
blog_username = 'user'
blog_password = 'pass'
blog_url = 'http://yourblog.com'

填入你的用户名、密码、博客地址，保存即可。

然后重新打开一个Vim，就可以敲:BlogList命令试试了。

Vimpress had been updated to 2.x, usage and configurations are now different, read the officle page in vim.org:

http://www.vim.org/scripts/script.php?script_id=3510

VimRepress is a broken fixed version of vimpress, a vim plugin to manage your wordpress. The name VimRepress is given by Justin Sattery described it a "A mod of a mod of a mod of Vimpress" which i like alot :) , who commented in my previous post together with some bug fixed code. Many thanks to Justin.

Features compared to the old vimpress:

• BlogNew command keep current buffer as post content.
• BlogUpload command to upload images or other files.
• BlogList command can be specify how many recent posts to list.
• BlogSave command can save as draft, or just publish.
• BlogPreview command works same as BlogSave, but open a browser for a preview page.
• BlogCode command to append a code block of <pre> element for code highlight.

Download: From Google Code

SVN Version: http://ptcoding.googlecode.com/svn/trunk/vimpress/

Full Help Manual:

*vimpress.txt* Manage wordpress blog from Vim
 
Vimpress
 
Author: Adrien Friggeri <adrien@friggeri.net>
        Preston M. [BOYPT] <pentie@gmail.com>
 
==============================================================================
 
== Install ==
 
Download vimpress-1.x.x.zip, extract it in your .vim directory:
 
cd ~/.vim
  unzip /where/you/downlaod/vimpress-1.x.x.zip
 
== Configure ==
 
Edit ~/.vim/plugin/blog.vim, search "Settings", you will find such section:
 
#####################
#      Settings     #
#####################
 
blog_username = 'user'
blog_password = 'pass'
blog_url = 'http://yourblog.com'
 
Fill in this about your blog, save, thats all.
 
== Using Vimpress ==
 
Vimpress Commands:
 
:BlogList [<count>]
   Lists articles in the blog, defaultly recent 30, use an arg. to specify.
 
:BlogNew
   Open for a new post. Contents in current buffer will append in the post edit area.
 
:BlogOpen <id>
   Open a post <id> for editing.
 
:BlogSave <draft|publish>
   Saves the article, defaultly as draft, an arg. to specify.
 
:BlogPreview <draft|publish>
   Same as :BlogSave, will open a browser to preview current post. You have to login
   in your browser to preview the draft post.
 
:BlogUpload <file>
   Upload media file to blog. Appends img element after cursor.
 
:BlogCode [<code type>]
   Append a section of a <pre> element, which could be hilighted by wp-syntax plugin.
   When give a code type, will fillin the element for syntax.