Passage à Django 1.9 #3245
Passage à Django 1.9 #3245
Conversation
|
Laisser tomber "Tests en parallèle" me semble être un choix judicieux dans cette mise à jour déjà énorme. |
|
+1 @GerardPaligot |
|
Dans la mesure où c'est très simple à mettre en place (une dépendance à ajouter) si ça passe je mettre cette dépendance sinon on oublie. @artragis : migré ? |
|
bah je veux dire "rendu compatible django 9) Le 16 décembre 2015 à 11:56, Laville Augustin notifications@github.com a
|
|
Super alors \o/ |
|
Notons qu'il semblerait que j'ai ajouté une erreur dans les forum en ajoutant une migration qui était marquée comme manquante chez moi mais qui était déjà ajoutée. La 004 des forum peut être supprimée. |
|
Fait, merci. |
|
Pas de nouvelle ici, j'ai contacté 2 auteurs par mail pour qu'ils mergent mes PR. Je pense que les projets ne sont pas très actifs avec les fêtes. |
|
Je vais tenter de te faire une PR dans le mois pour passer à la prochaine version de Haystack comme ça, quand il merge le fix pour django 1.9, on pourra continuer la migration. |
|
De plus, je crois que dans la recherche, on fait pas la différence entre les catégories et les tags, faudrait harmoniser tout ça avec le reste mais pour ça, je ne sais pas si j'aurais le temps. |
|
@DevHugo super, je vais essayer de bosser un peu sur ça début janvier, ça semble bouger un peu côté dépendances. Pour les tags et les catégories faudra attendre la ZEP-25 non ? Note : màj de crispy à venir début janvier avec le fix qui ne manque |
|
Ouai, je pourrais faire une PR sur ta branche zep_25, le souci est que je peux pas te garantir ni de date, ni de faisabilité et je veux pas que tu sois bloquer à cause de moi. Enfait, j'ai parcouru et non lu, les specs, je ne sais même pas la quantité de travail que ça demande. J'ai pas du tout le temps libre en se moment. Je tente et je fais au mieux ^^ ! |
|
faudrait un rebase pour que ça prenne en compte le fait qu'on n'a plus les articles et tuto du vieux module, ça te simplifiera la tâche. |
|
Bon alors pas mal d'améliorations ici. Plus d'erreurs sur les tests. Il reste des fails mais c'est en cours de correction. Les tests en parallèle ça sera vraiment du bonus et uniquement si ça passe sur Travis (c'est buggé chez moi). Pour les dépendances on en a encore 7 qui ne sont pas officiellement compatibles dont :
|
|
J'ai peur pour la librairie |
|
On a des solutions de secours à |
|
développer non même?N 2016-01-06 8:30 GMT+01:00 SpaceFox notifications@github.com:
|
Vu comment ça à l'air employé quand on fait une recherche, si on maintiens ça nous même, on va se manger des requêtes de plein de devs' |
|
a priori il existe une méthode simple pour le court terme : utiliser le fork de gustavi. Ensuite, à l'association de voir, c'est la "beauté" du monde opensource. |
Ben si on a pas le choix ... |
|
L'utilisation qu'on fait de la librairie est faible. On se contente de dire Sinon, on a déjà forker un projet, ça c'est bien passé donc je pense qu'il Tu en pense que c'est faisable avec un middleware @andr0 ? |
|
La bibliothèque Sinon, c'est qui Andr0 ? ^^ |
class CorsMiddleware(object):
def process_response(self, request, response):
origin = request.META.get('HTTP_ORIGIN')
if self.is_enabled(request) and origin:
# todo: check hostname from db instead
url = urlparse(origin)
if settings.CORS_MODEL is not None:
model = get_model(*settings.CORS_MODEL.split('.'))
if model.objects.filter(cors=url.netloc).exists():
response[ACCESS_CONTROL_ALLOW_ORIGIN] = origin
if (not settings.CORS_ORIGIN_ALLOW_ALL and
self.origin_not_found_in_white_lists(origin, url)):
return response
response[ACCESS_CONTROL_ALLOW_ORIGIN] = "*" if (
settings.CORS_ORIGIN_ALLOW_ALL and
not settings.CORS_ALLOW_CREDENTIALS) else origin
if len(settings.CORS_EXPOSE_HEADERS):
response[ACCESS_CONTROL_EXPOSE_HEADERS] = ', '.join(
settings.CORS_EXPOSE_HEADERS)
if settings.CORS_ALLOW_CREDENTIALS:
response[ACCESS_CONTROL_ALLOW_CREDENTIALS] = 'true'
if request.method == 'OPTIONS':
response[ACCESS_CONTROL_ALLOW_HEADERS] = ', '.join(
settings.CORS_ALLOW_HEADERS)
response[ACCESS_CONTROL_ALLOW_METHODS] = ', '.join(
settings.CORS_ALLOW_METHODS)
if settings.CORS_PREFLIGHT_MAX_AGE:
response[ACCESS_CONTROL_MAX_AGE] = \
settings.CORS_PREFLIGHT_MAX_AGE
return responseCette partie là doit suffire, non ? |
|
Aux quelques dépendances près et théoriquement, oui. |
|
Je serai pour utiliser mon fork temporairement car je n'ai changé que 4 lignes. Dans un second temps on relance le dev une ou deux fois et sans nouvelle dans un mois on prend une décision : on fork ou on inclus le strict minimum qu'on utilise dans notre projet. @SpaceFox ça te va ? |
|
Ça me paraît bien. PS : idéalement, on rappatrie ton fork sur le compte de ZdS. |
C'est l'idée que j'avais aussi et je plussoie. Faudrait juste que ton fork passe sur Travis parce que c'est pas le cas de ta PR (sur le projet |
|
J'ai rajouté les informations sur les Warning et crée un PR pour django-munin. @SpaceFox tu peux fork le projet et me donner les droits ? Je fais une PR prope des que c'est bon :) |
Thanks to @DevHugo for its contribution.
|
Bon alors bonne nouvelle : on peut tester ça !! Ils reste des dépendances temporairement pas full OK dans le dernière version mais là ça passe. C'est rebase, tout beau tout propre. |
| # full compatibility with django 1.8 and 1.9 | ||
| django-crispy-forms==1.6.0 | ||
| # TODO django-haystack | ||
| https://github.com/gustavi/django-haystack/archive/django_19.zip |
There was a problem hiding this comment.
Ca vient d'où ? Comment pouvons-nous savoir que c'est pas une dépendance foireuse ? :/
There was a problem hiding this comment.
ça vient de "haystack est trop lent à réagir alors on utilise
temporairement le dépôt de gustavi".
En tout cas c'est approuvé par @SpaceFox.
Le 17/01/2016 17:26, Gérard Paligot a écrit :
In requirements.txt
#3245 (comment):coverage==4.0.1
-django-crispy-forms==1.4.0
-django-haystack==2.4.1
-django-model-utils==2.2
-django-munin==0.2.0
+# full compatibility with django 1.8 and 1.9
+django-crispy-forms==1.6.0
+# TODO django-haystack
+https://github.com/gustavi/django-haystack/archive/django_19.zipCa vient d'où ? Comment pouvons-nous savoir que c'est pas une
dépendance foireuse ? :/—
Reply to this email directly or view it on GitHub
https://github.com/zestedesavoir/zds-site/pull/3245/files#r49948467.
There was a problem hiding this comment.
j'ai tendance à dire que :
django-haystack/django-haystack#1277 est la
bonne chose
Le 17/01/2016 17:31, Gérard Paligot a écrit :
+# TODO django-haystack
There was a problem hiding this comment.
There was a problem hiding this comment.
Il n'y a aucun risque pour ZdS ?
There was a problem hiding this comment.
Si c'est rouge, c'est sans doute pas pour faire jolie. @SpaceFox tu es vraiment ok avec ça ?
There was a problem hiding this comment.
Non, la modification doit être propre même si elle est de notre côté.
There was a problem hiding this comment.
J'attends qu'il merge ma PR mais c'est pas un violent lui non plus.
En tous cas la recherche fonctionne. Sinon tout le reste est testable alors go QA.
There was a problem hiding this comment.
Ping le la ou tu as fait la PR. On reçoit pas de mail de mémoire quand on a une pr sur son repo.
acdha self-assigned this 3 hours ago
acdha added this to the v2.5.0 milestone 3 hours ago
acdha c'est le mainteneur principal du projet de django-haystack
|
|
|
Si je regarde la situation actuelle de cette PR, nous avons plusieurs points bloquants :
Est-ce qu'il ne serait pas plus pertinent de descendre à Django 1.8 qui est encore maintenue, qui est supportée par toutes les dépendances manquantes et qui pourrait aider au merge de cette branche dans la branche dev. Qu'est ce que vous en pensez ? |
|
La seule dépendance qui fait chier c'est django-haystack. Le reste ça relève du warning. |
|
On peut commencer à QA sans et passer le code en béta. Peut-être que cela avancé du côté de haystack d'ici là. |
|
C'est exactement ce que j'ai dit il y a 6 jours. |
|
Ma manière détourné de relancer le sujet en disant pas juste +1. |
|
Les gars, haystack est compatible 1.9 o/ |
|
Il reste quoi d'autre d'incompatible ? |
|
Je regarde ça la semaine prochaine OK ? |
|
Juste pour signaler que toutes les dépendances sont compatibles mais n'ont pas toutes une version publiée sur Pypi. Je fais une PR quand ça sera le cas et j'essaye de relancer régulièrement les auteurs. |
|
En attendant, on peut penser à travailler sur la compatibilité Python 3. Rien ne presse de ce côté ci. |
Suite de #3235 avec un rebase et plus propre
QA
Tester absolument tout.
Travail qu'il reste à faire pour passer à 1.9