Handle virtualenv development mode
Looking for VIRTUAL_ENV environment variable as a sign of virtualenv
activation. This at least works for developing CubicWeb itself (not sure yet
about cubes). And it makes `tox --develop` work as well.
Add a test for cwconfig._find_prefix within a virtualenv.
In tox.ini, use `develop option`_ accordingly. This makes tox running
significantly faster since it avoids building and installing the sdist. Aside,
the "develop" install is now performed *after* all test requirements are
processed, which means that the cubicweb package should always be the one from
source -- instead of a released version pulled by a cube through test
dependencies, which may occur in "recreate" step.
.. _`develop option`: <http://tox.readthedocs.org/en/latest/config.html#confval-usedevelop=BOOL
#!/bin/sh -e
### BEGIN INIT INFO
# Provides: cubicweb
# Required-Start: $remote_fs $syslog $local_fs $network
# Required-Stop: $remote_fs $syslog $local_fs $network
# Should-Start: postgresql
# Should-Stop: postgresql
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start cubicweb application at boot time
### END INIT INFO
# FIXME Seems to be inadequate here
cd /tmp
# FIXME Work-around about the following lintian error
# E: cubicweb-ctl: init.d-script-does-not-implement-required-option /etc/init.d/cubicweb start
#
# Check if we are sure to not want the start-stop-daemon machinery here
# Refer to Debian Policy Manual section 9.3.2 (Writing the scripts) for details.
case $1 in
force-reload)
python -W ignore /usr/bin/cubicweb-ctl reload --force
;;
status)
python -W ignore /usr/bin/cubicweb-ctl status
;;
start|stop|restart|*)
python -W ignore /usr/bin/cubicweb-ctl $1 --force
;;
esac