Guardo un directorio de proyectos/en mi directorio personal (en Linux). Cuando tengo que comenzar un nuevo proyecto, hago un nuevo directorio, brevemente nombrado (que describe suficientemente el proyecto) en proyectos /; eso se convierte en la raíz de un nuevo virtualenv (con --no-site-packages) para ese proyecto.
Dentro de ese directorio (después de que he instalado el canal, lo obtuve y haya instalado la copia de django con la que trabajaré), "django-admin.py startproject" un subdirector, normalmente por el mismo breve nombre. Ese directorio se convierte en la raíz de mi repositorio hg (con hg init rápido y ci), sin importar cuán pequeño sea el proyecto.
Si hay alguna posibilidad de compartir el proyecto con otros desarrolladores (un proyecto para el trabajo, por ejemplo), incluyo un pip requirements.txt en la raíz del repositorio. Solo requisitos del proyecto entran allí; django-debug-toolbar y django-extensions, staples para mi flujo de trabajo dev, no son requisitos del proyecto, por ejemplo. Sur, cuando lo usamos, es.
En cuanto al proyecto django, normalmente mantengo el settings.py predeterminado, posiblemente con algunos cambios, y agrego el convenio local_settings al final del mismo (try: from local_settings import *; except ImportError: pass). La configuración del entorno específico de mi y otros desarrolladores (agregar django-extensions y django-debug-toolbar a las aplicaciones instaladas, por ejemplo) va en local_settings.py, que es no registrado en el control de versiones. Para ayudar a un nuevo desarrollador, puede proporcionar una plantilla de ese archivo como local_settings.py.temp, o algún otro nombre que no se use para ningún otro propósito, pero creo que esto innecesariamente complica el repositorio.
Para proyectos personales, normalmente incluyo un README si planeo liberarlo públicamente. En el trabajo, mantenemos entornos de Trac y una buena comunicación para que los nuevos desarrolladores estén al día en un proyecto.
En cuanto a la implementación, como mencioné anteriormente, escuché que el tejido es realmente bueno para ese tipo de scripting local/remoto automatizado, aunque realmente no he tenido la oportunidad de investigarlo.
Para los no iniciados, una sesión de shell típico para esto podría ser similar al siguiente:
$ cd ~/projects/
$ mkdir newproj
$ cd newproj/
$ virtualenv --no-site-packages .
$ source bin/activate
(newproj)$ pip install django django-debug-toolbar django-extensions
... installing stuff ...
(newproj)$ django-admin.py startproject newproj
(newproj)$ cd newproj/
(newproj)$ hg init .; hg ci -A -m "Initial code"
Ahhhh haciendo el pago en el virtualenv. Esto parece un buen enfoque. ¡Gracias! –
Ahora que comencé a hacer esto, me encontré con un problema que tenía antes. Cuando el repositorio entra en el virtualenv de esta manera, no tengo un lugar para poner cosas adicionales (no desplegadas) en VC. Por ejemplo, si tuviera que usar fabric, me gustaría que mi archivo fabf fuera versionado, pero ahora la raíz del proyecto django es la parte superior de mi VC. Supongo que hacer subdirectorios primero y luego poner el proyecto Django en un subdirectorio funcionaría. Seguiré intentando. –
En el trabajo, la estructura dir que han adoptado es 'project/env/www/proj /', donde "project" es un contenedor base para todo, "env" es la raíz virtualenv, "www" es el apache del proyecto " DocumentRoot "(aunque realmente no debería tener un DocumentRoot con un proyecto django), y" proj "es la raíz del proyecto django y el repositorio fuente. Puede tomar este enfoque y mover el repositorio un nivel hacia arriba (para que "www" se convierta en la raíz del repo), si realmente necesita versiones de archivos fuera de la raíz de django. – eternicode