FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Cita:
// Saludos |
#2
|
||||
|
||||
Interesante... ¿No?
Como sabemos, no todos tenemos la plata para pagar un servidor dedicado y muchas veces las aplicaciones no tendrán tanta demanda como para justificar este gasto. Ese es el punto fuerte de PHP, me atrevería a decir que todos los proveedores de hospedaje web compartido ofrecen soporte pare este. Con Python/Django la situación es otra . Cualquier aplicación/script python puede correr en el servidor web de varias formas, mi favorita es FastCGI (aquí las demás). Entonces, lo que necesitamos para tener django corriendo en un servidor web es, Python en el Servidor y soporta para FastCGI (en mi caso). FastCGI es soportado casi en la mayoría de los servidores web, aquí el punto a favor. Python está en casi todas las distribuciones linux desde que se instala, sin embargo, para instalar django es necesario agregar a nuestro "PYTHON_PATH" la ubicación tanto de Django, como de todos las herramientas adicionales que utilizaremos (reportlab, pil, etc) que de manera predeterminada no estarán en el servidor. El problema se presenta al momento de quered instalar estas herramientas, podemos hacerlo manual, agregando una a una las ubicaciones de estos paquetes dentro de el archivo de arranque del fastcgi, pero sería un trabajo sucio. La solución a esto es: Primero: Compilar los fuentes de Python e instalarlo dentro de la carpeta de usuario en el servidor, así tendríamos una instalación privada de python. En mi caso fué muy fácil gracias a que en esta cuenta tengo acceso vía ssh, pero pienso que igual podría compilarlo en local y cargarlo al servidor. Compilados los fuentes, podemos instalar cualquier paquete python, descargamos los fuentes de estos y ejecutamos /home/<user>/bin/python setup.py install. Este comando instalará el paquete en la ruta de nuestro python, no el que tenía el servidor. Así instalamos django y cualquier otro que necesitemos. Segundo: Como tenemos soporte fastcgi, tenemos que crear un archivo en nuestro directorio cgi-bin (el comun en servidores compartidos), llamémosle "cargadorfcgi.py", con el siguiente contenido: Código:
#!/home/<user>/bin/python import sys, os os.environ['DJANGO_SETTINGS_MODULE'] = "djangoproject.settings" from django.core.servers.fastcgi import runfastcgi runfastcgi(method="threaded", daemonize="false") Luego indicamos en la tercera línea el módulo que deberá cargar con la configuración del proyecto. y sobreescribimos la url para que todas las peticiones a la raiz sean enviadas al fastcgi, quedando el .htaccess de esta manera (no soy ningun experto en esto, quizá se pueda mejorar) Código:
RewriteEngine On RewriteBase / RewriteRule ^(media/.*)$ - [L] RewriteCond %{REQUEST_URI} !(cgi-bin/cargadorfcgi.py) RewriteRule ^(.*)$ cgi-bin/cargadorfcgi.py/$1 [L] Espero que sirva de algo. Saludos Cordiales |
#3
|
||||
|
||||
Joder! Mira todo lo que había detrás de una frasesita
Es lo bueno de este tipo de hilos; que resultan muy iluminadores. Mira que yo me hubiera ido de frente con mod_python Viendo el enlace que pones, aun cuando en mi caso sí podría acceder a la configuración del servidor, me entero que no es la mejor opción. // Saludos Última edición por roman fecha: 22-10-2014 a las 07:17:44. Razón: Una horrible falta de ortografía |
#4
|
||||
|
||||
Jejejejeje ... A veces no hay inspiración para escribir
Cita:
mod_python no lo he utilizado nunca, ni siquiera en local pues desde que uso Django leí esta información en el enlace que cito. Saludos. |
#5
|
||||
|
||||
D-MO:
No sé si ya lo mencionaste. ¿Con que motor de datos has trabajado con python? // Saludos |
#6
|
||||
|
||||
Cita:
Con el sistema funcionando con slqite3, descargo la información (registros en la bd) con la que he trabajado para no tener que volver a llenar la nueva bd a mano. Código:
python manage.py dumpdata > dump_XXX.json Código:
python manage.py syncdb Código:
python manage.py loaddata dump_XXX.json Pero respondiendo a tu pregunta, en desarrollo siempre uso sqlite3, en producción he usado MySQL (mas que todo en cuentas compartidas que no proveen soporte a PostgreSQL) y una o dos con PostgreSQL. Acá en el trabajo tengo una aplicación funcionando con sqlite3, no tiene mucha demanda y ha funcionado muy bién. Para la aplicación que planteo acá pretendo usar PostgreSQL, aunque si la llego a desarrollar, al liberarla (planeo hacerlo bajo la licencia BSD) sabemos que podrá utilizarse con cualquier motor soportado por Django. Saludos. |
#7
|
||||
|
||||
¡Guau! ¿¡Así de transparente es el cambio!?
Este sólo mensaje tuyo debería bastar a cualquiera para probar el framework! // Saludos |
#8
|
||||
|
||||
Para una guía detallada, puedes también leer el capitulo dedicado a los lanzamientos de proyectos Django del libro de Django
Pero volviendo un poco al tema del hilo, en síntesis que opinan sería lo mejor para hoy y el futuro. Teniendo en cuenta los nuevos modelos de distribución SaaS y la nube. |
#9
|
||||
|
||||
Una fuente de información muy buena, complementa la documentación de django. Hay algunas cosas desactualizadas pues está escrito para la versión 1.0 de django (ya va por la 1.3) pero si hay buena información.
Por las cosideraciones a tomar según esta frase, de las opciones que dás, opino que django. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Querys en DataSnap | juank1971 | Conexión con bases de datos | 10 | 15-07-2014 13:04:55 |
Error en insercion con Datasnap | rruffino | SQL | 3 | 16-03-2010 17:38:02 |
Comom saber si tengo instalado lamp | Faust | Linux | 3 | 16-01-2009 02:07:00 |
Turotial datasnap | Osorio | Providers | 2 | 20-09-2006 13:36:10 |
Midas y DataSnap | Toni | Providers | 1 | 09-07-2003 18:30:47 |
|