Passer à Django 1.9

[SpaceFox]

Django 1.9 est sorti.

Devant les problèmes abscons auxquels on fait face avec Django 1.8, peut-être qu'un passage direct à la 1.9 nous aiderait ? (j'y crois moyen, mais sait-on jamais).

---

Ce qui a été fait :

• modification des dépendances (là ça va être chiant parce que j'ai 3 URL de repo github dans mon requirements.txt pour avoir des trucs à jour)
• modification des settings liées aux TEMPLATE (à confirmer que ça marche)
• reformatage complet des urls.py
• vérifier que tous les reverse() du site prennent un nom d'URL et non une vue sous la forme d'un str
• autres détails légers

Ce qui reste à faire :

• enlever les fonctions supprimer
• faire en sorte que les tests passent (j'ai 483 tests qui ne passent pas là)
• potentiellement réécrire tous les tests API
• mettre en place les tests en parallèle
• d'autres trucs que je ne vois pas là

Màj le 8 démbre

---

EDIT de gustavi :

Résumé de ce qui change pour Zeste de Savoir (désolé pour ce qui traine en anglais et que j'ai eu la flemme de traduire) :

• Django 1.9 nécessite Python 2.7, 3.4, ou 3.5
• Un nouveau hook : on_commit
• La possibilité d'ajouter des critères de validation des mots de passe
• Des nouveaux mixins niveau persmissions pour le CBV
• L'interface d'amdmin a eu un petit lifting très appréciable
• Possibilité de lancer des tests en parrallèl
• Support for multiple enclosures per feed item has been added. If multiple enclosures are defined on a RSS feed, an exception is raised as RSS feeds, unlike Atom feeds, do not support multiple enclosures per feed item.
• The new CSRF_TRUSTED_ORIGINS setting provides a way to allow cross-origin unsafe requests (e.g. POST) over HTTPS.
• SlugField now accepts an allow_unicode argument to allow Unicode characters in slugs.
• A WARNING level message for uncaught exceptions raised during the rendering of an {% include %} when debug mode is off (helpful since {% include %} silences the exception and returns an empty string).
• DEPRECIED : Passing a 3-tuple or an app_name to include()

[gustavi]

Surtout que :

With the release of Django 1.9, Django 1.7 has reached end-of-life. Django 1.7.11 is the final release of the 1.7 series and all users are encouraged to upgrade to Django 1.8+ as soon as possible so they can continue to receive security updates. Django 1.8 LTS will receive security updates until April 2018. Django 1.4 (the previous LTS) reached end of life on October 1, 2015. See the downloads page for a table of supported versions and the future release schedule.

[gustavi]

Spoiler :

Django now ships with the mixins AccessMixin, LoginRequiredMixin, PermissionRequiredMixin, and UserPassesTestMixin to provide the functionality of the django.contrib.auth.decorators for class-based views. These mixins have been taken from, or are at least inspired by, the django-braces project.

The test command now supports a --parallel option to run a project’s tests in multiple processes in parallel.

The admin sports a modern, flat design with new SVG icons which look perfect on HiDPI screens. It still provides a fully-functional experience to YUI’s A-grade browsers. Older browser may experience varying levels of graceful degradation.

[SpaceFox]

J'avoue ne pas avoir regardé la liste des nouveautés :)

[gustavi]

Pas de grosse nouveauté comme aux versions précédentes (migrations, templates autres que Django, python 3 etc), les 3 qui nous intéressent sont ici.

EDIT : ce qui change pour ZdS ajouté au premier message.

[artragis]

je clos ma PR pour django 1.8 alors?

[SpaceFox]

C'est peut-être plus simple de s'en servir comme base pour passer à 1.9 ? Qu'en pensent les experts ?

[gustavi]

Je me suis fondé dessus pour ma branche

[artragis]

si ça fonctionne chez toi parfait.

Le 02/12/2015 18:02, Laville Augustin a écrit :

Je me suis fondé dessus pour ma branche

—
Reply to this email directly or view it on GitHub
#3214 (comment).

[gustavi]

Je suis dessus.

Voir premier message pour l'avancement.

[gustavi]

PING @GerardPaligot

À quoi sert cette ligne : get_cache(extensions_api_settings.DEFAULT_USE_CACHE).clear()

En fait get_cache a été supprimé. Cette ligne est nécessaire ? Si oui par quoi on peut la remplacer ?

[GerardPaligot]

Je ne suis pas à l'origine de cette ligne mais je sais à quoi elle sert. Elle permet de réinitialiser le cache de l'API entre 2 tests.

Je ping @DevHugo qui est à l'origine de cette modification et qui pourrait sans doute mieux t'éclairer pour la remplacer par autre chose.

[gustavi]

Il semblerait qu'on ai trouvé une solution.

En revanche on a une dépendance pas à jour qui empêche de faire passer les tests : django-cors-headers. Je suis en train de voir si le dev maintient le truc et sinon je fork ça.

[DevHugo]

En gros, c'était liés à un souci avec les tests unitaires et memcache de mémoire. Quand on fessait une requête une, il mettait en cache le résultat, puis quand on fessait une requête 2, il nous retournait direct le cache alors que pour les tests unitaires c'était pas pertinent.

Je te laisse lire la conversation.