Virtualenv's activate script sets the VIRTUAL_ENV environment variable to the path of the virtualenv. Checking this variable is a reasonably common way to verify that execution is happening in a virtualenv. It would be convenient if this module's virtualenv handling set this environment variable.
The apache2_module module did not properly handle when a2enmod would
handle apache module dependancies. It would always return a state of
changed. I've updated the regular expression to properly parse that
output as well as the normal output. A good example of this is the
mod_proxy_http module.
The docs were a little bit out of date with what commands are available to be run. They also didn't explain that you could pass custom commands - I almost went down the path of trying to run our custom management commands with the generic Ansible `command` module.
The virtualenv parameter to the django_manage command is used to locate
the virtualenv and build it if necessary. Access to the virtualenv
executable is only needed if the virtualenv directory doesn't exist and
needs to be built. This patch allows for the situation where a
virtualenv that is not in the PATH was used to create a virtualenv prior
to running the django_manage module.
This commit removes the restriction on django management commands. If a command is unknown to the django installation, there will be a concise error produced.
for example:
tasks:
- name: invalid command
django_manage: virtualenv="/valid/virtualenv" app_path="/valid/app_path" command="nowaydude"
Results in:
failed: [hostname] => {"cmd": "python manage.py nowaydude", "failed": true}
msg: stdout: Unknown command: 'nowaydude'
Type 'manage.py help' for usage.
:stderr: Unknown django command: nowaydude
- passlib.apache.HtpasswdFile's 'default_scheme' was called 'default'
before passlib version 1.6
- while here also deal with passlib.apache.HtpasswdFile's older
'autoload' paramter vs the newer 'new' one.
