2009-02-17 14 views
18

Estoy tratando de crear mi primer sitio en Django y como yo estoy buscando, por ejemplo, aplicaciones por ahí a inspirarse, constantemente se tropiezan con un término llamado "aplicaciones reutilizables".Cómo volver a utilizar una aplicación reutilizable en Django

Entiendo el concepto de una aplicación que se puede volver a utilizar con bastante facilidad, pero los medios para reutilizar una aplicación en Django ya los he perdido. Pocas preguntas que me están molestando en todo el negocio son:

¿Cuál es la forma preferida de reutilizar una aplicación existente de Django? ¿Dónde lo pongo y cómo lo hago referencia?

Por lo que entiendo, la recomendación es ponerlo en su "PYTHONPATH", pero se rompe tan pronto como tengo que implementar mi aplicación en una ubicación remota a la que tengo acceso limitado (por ejemplo, en un servicio de alojamiento) .

Por lo tanto, si desarrollo mi sitio en mi computadora local y tengo la intención de implementarlo en un ISP donde solo tengo acceso ftp, ¿cómo reutilizo las aplicaciones Django de terceros para que si implemente mi sitio, el sitio sigue funcionando (p. ej., lo único con lo que puedo contar es que el proveedor de servicios tiene instalados Python 2.5 y Django 1.x)?

¿Cómo organizo mi proyecto Django para que pueda implementarlo fácilmente junto con todas las aplicaciones reutilizables que deseo utilizar?

Respuesta

25

En general, lo único que se requiere para usar una aplicación reutilizable es asegurarse de que esté en sys.path, para que pueda importarla desde el código de Python. En la mayoría de los casos (si el autor sigue las prácticas recomendadas), el tarball o paquete reutilizable de la aplicación contendrá un directorio de nivel superior con documentos, un archivo README, un setup.py y luego un subdirectorio que contiene la aplicación real (consulte django-voting para obtener un ejemplo; la aplicación en sí está en el subdirectorio "votación"). Este subdirectorio es lo que debe colocarse en su ruta de Python. Los métodos posibles para hacer que incluyen:

  • corriendo pip install appname, si la aplicación se ha cargado en PyPI (en estos días la mayoría son)
  • la instalación de la aplicación con setup.py install (esto tiene el mismo resultado que pip install appname, pero requiere que por primera descarga y descomprimir el código usted mismo; pip lo hará por usted)
  • enlaces simbólicos manualmente el directorio de código a su pitón directorio site-packages
  • usando software como virtualenv para crear un "entorno Python virtual" que tiene su o wn site-packages directory, y luego ejecuta setup.py install o pip install appname con ese virtualenv activo, o colocando o enlazando simbólicamente la aplicación en los paquetes de sitio de virtualenv (muy recomendable sobre todas las opciones de "instalación global", si valoras tu cordura futura)
  • colocar la aplicación en algún directorio donde va a colocar varias aplicaciones, y luego agregó que el directorio a la variable de entorno PYTHONPATH

usted sabrá que lo tienes en el lugar correcto si se puede disparar una Intérprete de Python e "importación de votación" (por ejemplo) sin obtener un ImportError.

En un servidor donde solo tiene acceso FTP, su única opción es realmente la última y deben configurarse por usted.Si afirman que son compatibles con Django, deben proporcionar algún lugar donde puede cargar paquetes y estarán disponibles para su importación en Python. Sin conocer los detalles de su servidor web, es imposible decir cómo estructuran eso para usted.

+0

Gracias, eso fue útil. :) –

2

una vieja pregunta, pero aquí es lo que hago:

Si está utilizando un sistema de control de versiones (VCS), sugiero poner todas las aplicaciones reutilizables y bibliotecas (incluyendo Django) que sus necesidades de software en el VCS. Si no quiere ponerlos directamente debajo de la raíz de su proyecto, puede modificar settings.py para agregar su ubicación a sys.path.

Después de eso, la implementación es tan simple como clonar o verificar el repositorio de VCS en cualquier lugar que desee usarlo.

Esto tiene dos beneficios adicionales:

  • desajustes de versión; su software siempre usa la versión con la que lo probó, y no la versión que estaba disponible en el momento de la implementación.
  • Si varias personas trabajan en el proyecto, nadie más tiene que encargarse de instalar las dependencias.

Cuando sea el momento de actualizar la versión de un componente, actualícela en su VCS y luego propague la actualización a sus implementaciones a través de ella.

+0

Me inclino por la ruta virtualenv. Es un enfoque mucho más limpio y no es demasiado difícil tener el guión de configuración virtualenv para que los "committers" también lo tengan bien configurado (soy tan flojo como cualquiera, así que cada vez que siento que quiero restar, prefiero un buen script ordenado que volverá a crear mi entorno a un montón de pasos manuales ...) –

Cuestiones relacionadas