Django 1.7, otro estilo, otro sazón [+Descarga]

¡Hola a todos! Finalmente, luego de casi un año de desarrollo, ya está con nosotros desde el pasado 2 de septiembre, el tan esperado, Django 1.7, versión que desde los comienzos de su desarrollo se perfiló como el mayor estreno de Django desde la versión 1.0.

django.17

Características

Entre las características que trae esta nueva entrega tenemos:

  • Un nuevo sistema de migración de bases de datos integrado. También están disponibles las notas para actualizar desde South (una popular aplicación de terceros que proporciona la funcionalidad de migración).
  • Un concepto rediseñado de aplicaciones Django. Las aplicaciones Django ya no están ligadas a la existencia de archivos de modelos, y ahora se pueden especificar los datos de configuración y el código que se ejecuta cuando Django se pone en marcha.
  • Mejoras en la API de modelo Field para soportar las migraciones y, en el futuro, para permitir una fácil incorporación del  soporte de llave compuesta del ORM de Django.
  • Mejoras para las clases personalizadas Manager y QuerySet, permitiendo una inversa relación de recorrido para especificar el Manager a usar, y la creación de un Manager de una clase QuerySet personalizada.
  • Un framework extensible de comprobación del sistema que puede ayudar a los desarrolladores en la detección y el diagnóstico de errores (OMG!!!).

Django 1.7 también cuenta con nuevas características menores (Minor Features) en los módulos:

Compatibilidad

Django 1.7 requiere Python 2.7 o superior, aunque es muy recomendable la última versión menor. El soporte para Python 2.6 se ha retirado y se ha añadido para Python 3.4.

Este cambio debe afectar sólo a un pequeño número de usuarios de Django, ya que la mayoría de sistemas operativos vendedores de hoy tienen a Python 2.7 o posterior como su versión por defecto. Los que todavía estén utilizando Python 2.6, sin embargo, tendrá que atenerse a Django 1.6 hasta que pueda actualizar su versión de Python.

Soporte

Además, con el lanzamiento de Django 1.7, Django 1.5 ha llegado al final de su vida. Como tal, Django 1.5.10 es la versión final de la serie 1.5. Django 1.6 seguirá recibiendo el apoyo hasta el lanzamiento de Django 1.8. Django 1.4 es un long-term support release, y contará con el apoyo al menos hasta marzo de 2015.

Conclusiones

Esto fue solo un extracto. Para probarlo pueden descargarlo del sitio oficial o desde PyPI, esperar a que lo empaqueten para la distro de tu preferencia o si alguien lo descarga y me lo hace llegar lo puedo compartir descargarlo acá sin problemas. Para mayor información consulten las notas del release, que por cierto, están cargadas de detalles. ¡Hasta la próxima! 😉

 

Django-1.7.tar.gz (447 descargas)

 

Más Información: Django 1.7 Release notes.

16 comentarios » Puedes dejar tu comentario también

  1. 00

    Ozkar

    dijo:

    Firefox 32.0a1 Fedora

    No me quedó muy claro que las apps ya no están ligadas a los models. Tampoco es que le caí a fondo, si tuve que hacer un ‘hack’ a mi manage.py, así:
    import django
    django.setup()
    para que AppConfig no me diera conflictos, ya que mi proyecto viene conmigo desde Django 1.6.
    Lo de las migraciones, se agradece un mundo.
    Yo tengo el tarball y la documentación, aunque me decanto más por usar el development trunk que descargo desde GitHub.

  2. 00

    Oclay

    dijo:

    Chromium 31.0.1650.63 Ubuntu

    Bueno gente cuando van a hablar de la combinación Django + Nginx,cual es la mejor forma de implemetarla??

  3. 00

    Y@i$el

    dijo:

    Chromium 35.0.1916.153 Debian GNU/Linux

    @Oclay pronto mano, en cuanto tenga un chance que estoy hasta el cuello en el trabajo. No creas que se me ha olvidado.

  4. 00

    krlos

    dijo:

    Firefox 30.0 Ubuntu

    Hola, me podrían hacer una breve comparación de django vs otros frameworks de otros lenguajes??? Sobre que es lo bueno y lo malo. Algo generalizado, no 1 por 1.

  5. 00

    Vhagar

    dijo:

    Firefox 31.0 Windows 8.1 x64 Edition

    Si alguien lo descarga plis compartalo mi user es oviera

  6. 00

    raven

    dijo:

    Google Chrome 38.0.2071.0 Windows 8.1 x64 Edition

    @Oclay
    Yo sirvo con gunicorn, hago proxy inverso con nginx y manejo las instancias de gunicorn con supervisor.

  7. 00

    Eddy Ernesto del Valle Pino

    dijo:

    Chromium 36.0.1985.125 Ubuntu x64

    @raven, bien hecho… así lo hago, eso funciona súper en talla.

  8. 00

    Dariem

    dijo:

    Firefox 30.0 Nova x64

    @raven
    @Eddy Ernesto del Valle Pino

    ¿Se puede configurar como servidor nginx sin usar gunicorn? ¿Qué ventajas me ofrece utilizar gunicorn?

  9. 00

    raven

    dijo:

    Google Chrome 35.0.1916.153 GNU/Linux

    Todos los frameworks de python que he usado, entre ellos django, tienen su propio servidor wsgi pero todos ellos (los servidores) son de juguete. Para un despliegue serio necesitas un servidor WSGI implementado para estos menesteres gunicorn es el mejor que conozco (es bastante rápido, puede hacer balanceo de carga…) y es muy sencillo de usar ya que, gracias a las bondades de WSGI puede servir aplicaciones de cualquier framework que soporte el estándar (flask, django, bottle, pyramid ….) con solo exponer la app. Esto último se puede hacer normalmente con una sola linea de bash, así que no es nada que te haga perder tiempo.

  10. 00

    dhunter

    dijo:

    IceWeasel 31.0 GNU/Linux x64

    @Oclay
    Si sirves con gunicorn haces un proxy_pass, esto usa http normal para comunicarse, recuerda hacer un include proxy_params.

    Y si sirves con uwsgi (el modo emperor es la hostia divina y deja obsoleto a supervisor) entonces puedes aprovechar que nginx “habla” su protocolo especial.

    uwsgi_pass unix:///tmp/uwsgi.sock;
    include uwsgi_params;

    http://gunicorn-docs.readthedocs.org/en/latest/deploy.html
    http://uwsgi-docs.readthedocs.org/en/latest/Nginx.html

  11. 00

    dhunter

    dijo:

    IceWeasel 31.0 GNU/Linux x64

    @Dariem
    No, a diferencia de apache, nginx es solamente servidor de ficheros estáticos y proxy inverso, no ejecuta ningún lenguaje, necesitas gunicorn/uwsgi o algo para el código dinámico.

    Generalmente el deploy típico es este:

    Clientes —> Nginx —> App Server (gunicorn o uwsgi) —> DB

  12. 00

    Dariem

    dijo:

    Firefox 30.0 Nova x64

    @raven
    @dhunter

    Gracias por sus explicaciones. Es que lo que estoy haciendo con Django por ahora lo tengo con Apache y no he tenido tiempo de investigar como desplegarlo con Nginx, aunque quiero hacerlo más adelante para ganar en escalabilidad. Ya con las explicaciones de ustedes sé por donde viene la cosa. Muchas gracias.

  13. 00

    OSIEL

    dijo:

    Google Chrome 35.0.1916.153 GNU/Linux x64

    También pueden instalarlo en la Universidad desde el proxy del pypi. pip install -i http://pypi.prod.uci.cu:8081/root/pypi/+simple/ django.

    Sobre el despliegue desde Junio estoy preparando un post cada vez que tengo un chance utilizando el método Nginx + Gunicorn + Supervisord, espero pronto poder sacarlo.

  14. 00

    Jorge Luis

    dijo:

    Google Chrome 37.0.2062.94 Mac OS X 10.9.4

    Ostia no sabía de ese repo pypi! Q bien!

  15. 00

    dhunter

    dijo:

    IceWeasel 31.0 GNU/Linux x64

    @Jorge Luis
    Siempre puedes hacerte tu propio repo pypi. https://github.com/wolever/pip2pi

  16. 00

    guille

    dijo:

    Firefox 24.0 Ubuntu

    @Ozkar
    En realidad creo que está mal explicado. Me acabo de leer la página de referencia y vi algunos cambios pero ninguno que tenga que ver con que las aplicaciones puedan existir sin ficheros de modelo.
    Lo que vi fue que crearon un sistema ahí de instrospección en el que tratan las aplicaciones como objetos y de ahí le vinculan en tiempo de ejecución todo lo demás. Es decir, la relación se hace desde la aplicación a todos los componentes y no a la inversa como era antes.

    Un saludo

Deja un comentario

Tu dirección de correo electrónico nunca será compartida.