django.py 3.2 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394
  1. """
  2. .. versionadded:: 0.9.2
  3. These functions streamline the process of initializing Django's settings module
  4. environment variable. Once this is done, your fabfile may import from your
  5. Django project, or Django itself, without requiring the use of ``manage.py``
  6. plugins or having to set the environment variable yourself every time you use
  7. your fabfile.
  8. Currently, these functions only allow Fabric to interact with
  9. local-to-your-fabfile Django installations. This is not as limiting as it
  10. sounds; for example, you can use Fabric as a remote "build" tool as well as
  11. using it locally. Imagine the following fabfile::
  12. from fabric.api import run, local, hosts, cd
  13. from fabric.contrib import django
  14. django.project('myproject')
  15. from myproject.myapp.models import MyModel
  16. def print_instances():
  17. for instance in MyModel.objects.all():
  18. print(instance)
  19. @hosts('production-server')
  20. def print_production_instances():
  21. with cd('/path/to/myproject'):
  22. run('fab print_instances')
  23. With Fabric installed on both ends, you could execute
  24. ``print_production_instances`` locally, which would trigger ``print_instances``
  25. on the production server -- which would then be interacting with your
  26. production Django database.
  27. As another example, if your local and remote settings are similar, you can use
  28. it to obtain e.g. your database settings, and then use those when executing a
  29. remote (non-Fabric) command. This would allow you some degree of freedom even
  30. if Fabric is only installed locally::
  31. from fabric.api import run
  32. from fabric.contrib import django
  33. django.settings_module('myproject.settings')
  34. from django.conf import settings
  35. def dump_production_database():
  36. run('mysqldump -u %s -p=%s %s > /tmp/prod-db.sql' % (
  37. settings.DATABASE_USER,
  38. settings.DATABASE_PASSWORD,
  39. settings.DATABASE_NAME
  40. ))
  41. The above snippet will work if run from a local, development environment, again
  42. provided your local ``settings.py`` mirrors your remote one in terms of
  43. database connection info.
  44. """
  45. import os
  46. def settings_module(module):
  47. """
  48. Set ``DJANGO_SETTINGS_MODULE`` shell environment variable to ``module``.
  49. Due to how Django works, imports from Django or a Django project will fail
  50. unless the shell environment variable ``DJANGO_SETTINGS_MODULE`` is
  51. correctly set (see `the Django settings docs
  52. <http://docs.djangoproject.com/en/dev/topics/settings/>`_.)
  53. This function provides a shortcut for doing so; call it near the top of
  54. your fabfile or Fabric-using code, after which point any Django imports
  55. should work correctly.
  56. .. note::
  57. This function sets a **shell** environment variable (via
  58. ``os.environ``) and is unrelated to Fabric's own internal "env"
  59. variables.
  60. """
  61. os.environ['DJANGO_SETTINGS_MODULE'] = module
  62. def project(name):
  63. """
  64. Sets ``DJANGO_SETTINGS_MODULE`` to ``'<name>.settings'``.
  65. This function provides a handy shortcut for the common case where one is
  66. using the Django default naming convention for their settings file and
  67. location.
  68. Uses `settings_module` -- see its documentation for details on why and how
  69. to use this functionality.
  70. """
  71. settings_module('%s.settings' % name)