@MathieuMD whou, ça fait plaisir une contrib bien sentie, merci :-).
J'ai juste 2 remarques avant de merger :
1. La django_debug_toolbar est plus à mettre dans le fichier requirements/dev.txt que requirements/base.txt
En prod, django_debug_toolbar n'est pas utilisée… et il serait dangereux qu'elle le soit par accident.
2. ALLOWED_HOST*S* (« S » oublié)
3. le SITE_URL devrait être dans la section "mandatory settings" (c'est moi qui l'avait mal rangé, mais puisque tu es dans les améliorations de cette partie… :p)
Je me rend compte que la gestion des différentes confs n'est pas très claire (settings/prod.pysettings/dev.py) ni bien documentée, désolé :x
@MathieuMD whou, ça fait plaisir une contrib bien sentie, merci :-).
J'ai juste 2 remarques avant de merger :
- 1. La django_debug_toolbar est plus à mettre dans le fichier *requirements/dev.txt* que *requirements/base.txt*
En prod, django_debug_toolbar n'est pas utilisée… et il serait dangereux qu'elle le soit par accident.
- 2. `ALLOWED_HOST*S*` (« S » oublié)
- 3. le `SITE_URL` devrait être dans la section "mandatory settings" (c'est moi qui l'avait mal rangé, mais puisque tu es dans les améliorations de cette partie… :p)
Je me rend compte que la gestion des différentes confs n'est pas très claire (*settings/prod.py* *settings/dev.py*) ni bien documentée, désolé :x
Effectivement, je ne suis pas sûr d'avoir compris comment on passe du dev à la prod. Mais c'est peut-être parce que je ne connais pas du tout Django... En tout cas, ça mériterait quelques clarifications, oui ! :p
La django_debug_toolbar est plus à mettre dans le fichier requirements/dev.txt que requirements/base.txt
Peut-être que je manque quelque chose, mais sans ajouter django_debug_toolbar dans base.txt, la toute première étape d'installation (./manage.py migrate) échoue :
Traceback (most recent call last):
File "./manage.py", line 11, in <module>
execute_from_command_line(sys.argv)
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
utility.execute()
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 338, in execute
django.setup()
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/apps/registry.py", line 85, in populate
app_config = AppConfig.create(entry)
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/apps/config.py", line 94, in create
module = import_module(entry)
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 994, in _gcd_import
File "<frozen importlib._bootstrap>", line 971, in _find_and_load
File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'debug_toolbar'
PS : j'ai déménagé le dépot de MathieuMD vers Intarnet : je vais refaire une PR depuis là-bas.
C'est noté pour `ALLOWED_HOSTS` et `SITE_URL`.
Effectivement, je ne suis pas sûr d'avoir compris comment on passe du dev à la prod. Mais c'est peut-être parce que je ne connais pas du tout Django... En tout cas, ça mériterait quelques clarifications, oui ! :p
> La django_debug_toolbar est plus à mettre dans le fichier requirements/dev.txt que requirements/base.txt
Peut-être que je manque quelque chose, mais sans ajouter `django_debug_toolbar` dans `base.txt`, la toute première étape d'installation (`./manage.py migrate`) échoue :
```
Traceback (most recent call last):
File "./manage.py", line 11, in <module>
execute_from_command_line(sys.argv)
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
utility.execute()
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 338, in execute
django.setup()
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/apps/registry.py", line 85, in populate
app_config = AppConfig.create(entry)
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/site-packages/django/apps/config.py", line 94, in create
module = import_module(entry)
File "/home/mathieu/dev/wifi-with-me/venv/lib/python3.6/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 994, in _gcd_import
File "<frozen importlib._bootstrap>", line 971, in _find_and_load
File "<frozen importlib._bootstrap>", line 953, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'debug_toolbar'
```
PS : j'ai déménagé le dépot de MathieuMD vers Intarnet : je vais refaire une PR depuis là-bas.
Peut-être que je manque quelque chose, mais sans ajouter django_debug_toolbar dans base.txt, la toute première étape d'installation (./manage.py migrate) échoue :
Dans le cas d'une installation en environnement de dév, tu dois faire un pip install -r requirements/dev.txt
Est-ce que tu peux l'ajouter à la doc ?
Une fois ta PR mergées, je m'appliquerais à compléter pour qu'on puisse bien comprendre cette histoire d'environnements de dév/prod etc…
Effectivement, je ne suis pas sûr d'avoir compris comment on passe du dev à la prod. Mais c'est peut-être parce que je ne connais pas du tout Django... En tout cas, ça mériterait quelques clarifications, oui ! :p
Installer l'outil ne devrait pas requérir de connaître django.
> Peut-être que je manque quelque chose, mais sans ajouter django_debug_toolbar dans base.txt, la toute première étape d'installation (./manage.py migrate) échoue :
Dans le cas d'une installation en environnement de dév, tu dois faire un pip install -r requirements/dev.txt
Est-ce que tu peux l'ajouter à la doc ?
Une fois ta PR mergées, je m'appliquerais à compléter pour qu'on puisse bien comprendre cette histoire d'environnements de dév/prod etc…
> Effectivement, je ne suis pas sûr d'avoir compris comment on passe du dev à la prod. Mais c'est peut-être parce que je ne connais pas du tout Django... En tout cas, ça mériterait quelques clarifications, oui ! :p
Installer l'outil ne devrait pas requérir de connaître django.
J'ai poussé quelques commits de plus sur le dépot https://code.ffdn.org/Intarnet/wifi-with-me/commits/master, qui sont bien pris en comptes dans ce PR, bien que ses liens référencent toujours l'ancien propriétaire MathieuMD, et sont donc cassés. :-/
Dis-moi si je dois faire quelque chose différemment.
Dans le cas d'une installation en environnement de dév, tu dois faire un pip install -r requirements/dev.txt
Ça c'est bien indiqué dans ta doc[1], pas de pb. Le problème c'est qu'il faut aussi jouer l'étape migrate aussi en prod (non ?), et c'est elle qui ne passe pas sans installer django_debug_toolbar.
Par contre, expliquer ce qu'apporte concrêtement l'environnement dev pourrait avoir son intérêt ;) (Bloquer les mails sortants ? Autre chose ?)
J'ai poussé quelques commits de plus sur le dépot https://code.ffdn.org/Intarnet/wifi-with-me/commits/master, qui sont bien pris en comptes dans ce PR, bien que ses liens référencent toujours l'ancien propriétaire MathieuMD, et sont donc cassés. :-/
Dis-moi si je dois faire quelque chose différemment.
> Dans le cas d'une installation en environnement de dév, tu dois faire un pip install -r requirements/dev.txt
Ça c'est bien indiqué dans ta doc[1], pas de pb. Le problème c'est qu'il faut aussi jouer l'étape `migrate` aussi en prod (non ?), et c'est elle qui ne passe pas sans installer `django_debug_toolbar`.
1. Par contre, expliquer ce qu'apporte concrêtement l'environnement dev pourrait avoir son intérêt ;) (Bloquer les mails sortants ? Autre chose ?)
Merci de te donner ce mal en dépit d'une mauvaise doc :-x.
Ça c'est bien indiqué dans ta doc[1], pas de pb. Le problème c'est qu'il faut aussi jouer l'étape migrate aussi en prod (non ?), et c'est elle qui ne passe pas sans installer django_debug_toolbar.
En fait, toutes les commandes qui commencent par ./manage.py, quand elles sont utilisées en prod, doivent-être préfixées de la sorte :
(et ça, c'est complètement non documenté je crois :-x).
Sans ce préfixe (var. d'environnement), c'est les paramnètres de développement qui s'appliquent.
Les différents environnements (prod/dév/test) apportent des configurations par défaut utiles à ces environnements, pour le dév, envoyer les mails dans la console, activer le debug, pour la prod, désactiver le debug, configurer les logs correctement, et empêcher le service de démarrer si la secret key n'est pas générée.
Salut,
Merci de te donner ce mal en dépit d'une mauvaise doc :-x.
> Ça c'est bien indiqué dans ta doc[1], pas de pb. Le problème c'est qu'il faut aussi jouer l'étape migrate aussi en prod (non ?), et c'est elle qui ne passe pas sans installer django_debug_toolbar.
En fait, toutes les commandes qui commencent par `./manage.py`, quand elles sont utilisées en prod, doivent-être préfixées de la sorte :
```
DJANGO_SETTINGS_MODULE=wifiwithme.settings.prod ./manage.py
```
(et ça, c'est complètement non documenté je crois :-x).
Sans ce préfixe (var. d'environnement), c'est les paramnètres de développement qui s'appliquent.
Les différents environnements (prod/dév/test) apportent des configurations par défaut utiles à ces environnements, pour le dév, envoyer les mails dans la console, activer le debug, pour la prod, désactiver le debug, configurer les logs correctement, et empêcher le service de démarrer si la secret key n'est pas générée.
J'ai poussé quelques commits de plus sur le dépot https://code.ffdn.org/Intarnet/wifi-with-me/commits/master, qui sont bien pris en comptes dans ce PR, bien que ses liens référencent toujours l'ancien propriétaire MathieuMD, et sont donc cassés. :-/
Il faut que tu ouvre une nouvelle PR dont l asource est Intarnet/master. En effet, gogs ne permet pas de changer la branche source d'une PR une fois qu'elle est créée.
> J'ai poussé quelques commits de plus sur le dépot https://code.ffdn.org/Intarnet/wifi-with-me/commits/master, qui sont bien pris en comptes dans ce PR, bien que ses liens référencent toujours l'ancien propriétaire MathieuMD, et sont donc cassés. :-/
Il faut que tu ouvre une nouvelle PR dont l asource est Intarnet/master. En effet, gogs ne permet pas de changer la branche source d'une PR une fois qu'elle est créée.
C'est ce que j'avais voulu faire, mais le bouton « Nouvelle Pull Request » était inactif, grisé (vert-de-grisé ?), bien que cette PR 57 était fermée, et je me suis rendu compte que mes nouveaux commits, faits sur le dépôt Intarnet, avaient été ajoutés à cette PR.
Peut-être que toi tu peux supprimer cette PR, pour que je puisse en faire une nouvelle avec les mêmes commits ?
C'est ce que j'avais voulu faire, mais le bouton « Nouvelle Pull Request » était inactif, grisé (vert-de-grisé ?), bien que cette PR 57 était fermée, et je me suis rendu compte que mes nouveaux commits, faits sur le dépôt Intarnet, avaient été ajoutés à cette PR.
Peut-être que toi tu peux supprimer cette PR, pour que je puisse en faire une nouvelle avec les mêmes commits ?
Pour avoir une prod qui marche (merci pour le DJANGO_SETTINGS_MODULE=wifiwithme.settings.prod ./manage.py je l'aurais pas trouvé tout seul avant d'avoir pas mal vieilli ;)) j'ai du bricoler wifiwithme/wsgi.py :
# Avant
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "wifiwithme.settings")
# Après
os.environ["DJANGO_SETTINGS_MODULE"] = "wifiwithme.settings.prod"
C'est peut-être pas très propre, mais j'ai pas trouvé mieux (sans, il braillait à cause du SECRET_KEY manquant). C'est d'ailleurs ce qui semble être conseillé par la doc Django, si je comprends bien.
Ça serait bien d'expliciter ça aussi, dans la partie dev vs. prod (ou de dire ce qu'il faut configurer d'autre, si ça c'est crado)
Quant à la conf Apache, FWIW :
WSGIDaemonProcess wifiwithme python-home=/var/www/intarnet.fr/wifi-with-me/venv python-path=/var/www/intarnet.fr/wifi-with-me
WSGIProcessGroup wifiwithme
WSGIScriptAlias / /var/www/intarnet.fr/wifi-with-me/wifiwithme/wsgi.py process-group=wifiwithme
Alias /moi-aussi/assets/admin/ /var/www/intarnet.fr/wifi-with-me/venv/lib/python3.5/site-packages/django/contrib/admin/static/admin/
<Directory /var/www/intarnet.fr/wifi-with-me/venv/lib/python3.5/site-packages/django/contrib/admin/static/admin/>
Require all granted
</Directory>
Alias /moi-aussi/assets/ /var/www/intarnet.fr/wifi-with-me/wifiwithme/static/
<Directory /var/www/intarnet.fr/wifi-with-me/wifiwithme/static>
Require all granted
</Directory>
<Directory /var/www/intarnet.fr/wifi-with-me/wifiwithme>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
Je suis preneur de suggestions ! :D
Pour avoir une prod [qui marche](https://intarnet.fr/moi-aussi/) (merci pour le `DJANGO_SETTINGS_MODULE=wifiwithme.settings.prod ./manage.py` je l'aurais pas trouvé tout seul avant d'avoir pas mal vieilli ;)) j'ai du bricoler `wifiwithme/wsgi.py` :
```python
# Avant
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "wifiwithme.settings")
# Après
os.environ["DJANGO_SETTINGS_MODULE"] = "wifiwithme.settings.prod"
```
C'est peut-être pas très propre, mais j'ai pas trouvé mieux (sans, il braillait à cause du `SECRET_KEY` manquant). C'est d'ailleurs ce qui semble être conseillé par [la doc Django](https://docs.djangoproject.com/en/1.11/howto/deployment/wsgi/modwsgi/), si je comprends bien.
Ça serait bien d'expliciter ça aussi, dans la partie dev vs. prod (ou de dire ce qu'il faut configurer d'autre, si ça c'est crado)
Quant à la conf Apache, FWIW :
```apache
WSGIDaemonProcess wifiwithme python-home=/var/www/intarnet.fr/wifi-with-me/venv python-path=/var/www/intarnet.fr/wifi-with-me
WSGIProcessGroup wifiwithme
WSGIScriptAlias / /var/www/intarnet.fr/wifi-with-me/wifiwithme/wsgi.py process-group=wifiwithme
Alias /moi-aussi/assets/admin/ /var/www/intarnet.fr/wifi-with-me/venv/lib/python3.5/site-packages/django/contrib/admin/static/admin/
<Directory /var/www/intarnet.fr/wifi-with-me/venv/lib/python3.5/site-packages/django/contrib/admin/static/admin/>
Require all granted
</Directory>
Alias /moi-aussi/assets/ /var/www/intarnet.fr/wifi-with-me/wifiwithme/static/
<Directory /var/www/intarnet.fr/wifi-with-me/wifiwithme/static>
Require all granted
</Directory>
<Directory /var/www/intarnet.fr/wifi-with-me/wifiwithme>
<Files wsgi.py>
Require all granted
</Files>
</Directory>
```
Je suis preneur de suggestions ! :D
C'est ce que j'avais voulu faire, mais le bouton « Nouvelle Pull Request » était inactif, grisé (vert-de-grisé ?), bien que cette PR 57 était fermée, et je me suis rendu compte que mes nouveaux commits, faits sur le dépôt Intarnet, avaient été ajoutés à cette PR.
Peut-être que toi tu peux supprimer cette PR, pour que je puisse en faire une nouvelle avec les mêmes commits ?
Je ne peux pas faire quoi que ça soit de plus que toi (c'est à dire avec des droits admin) qui faciliterait le truc à mon avis.
> C'est ce que j'avais voulu faire, mais le bouton « Nouvelle Pull Request » était inactif, grisé (vert-de-grisé ?), bien que cette PR 57 était fermée, et je me suis rendu compte que mes nouveaux commits, faits sur le dépôt Intarnet, avaient été ajoutés à cette PR.
certain que depuis la page https://code.ffdn.org/FFDN/wifi-with-me/pulls le bouton est grisé ? :-/
> Peut-être que toi tu peux supprimer cette PR, pour que je puisse en faire une nouvelle avec les mêmes commits ?
Je ne peux pas faire quoi que ça soit de plus que toi (c'est à dire avec des droits admin) qui faciliterait le truc à mon avis.
Pour avoir une prod qui marche (merci pour le DJANGO_SETTINGS_MODULE=wifiwithme.settings.prod ./manage.py je l'aurais pas trouvé tout seul avant d'avoir pas mal vieilli ;)) j'ai du bricoler wifiwithme/wsgi.py :
Ah, c'est bien vu, it's a bug ! Par contre utiliser setdefault me semble mieux (ça permet à quelqu'un qui souhaiterait surcharger ce paramètre de le faire). Tu ajouterais cette modif à ta PR ?
PS: tu as bien généré une SECRET_KEY placée dans ton local.py ?
> Pour avoir une prod qui marche (merci pour le DJANGO_SETTINGS_MODULE=wifiwithme.settings.prod ./manage.py je l'aurais pas trouvé tout seul avant d'avoir pas mal vieilli ;)) j'ai du bricoler wifiwithme/wsgi.py :
> Avant
>
> os.environ.setdefault("DJANGO_SETTINGS_MODULE", "wifiwithme.settings")
>
> Après
>
> os.environ["DJANGO_SETTINGS_MODULE"] = "wifiwithme.settings.prod"
Ah, c'est bien vu, it's a bug ! Par contre utiliser setdefault me semble mieux (ça permet à quelqu'un qui souhaiterait surcharger ce paramètre de le faire). Tu ajouterais cette modif à ta PR ?
PS: tu as bien généré une `SECRET_KEY` placée dans ton local.py ?
Si WSGIScriptAlias / alors le site web HTML à la racine est cassé (je ne m'en étais pas rendu compte tout de suite, bravo moi...).
Mais avec WSGIScriptAlias /moi-aussi ça ne fonctionne que si URL_PREFIX est non définit (ie. pasmoi-aussi/), et même ainsi, c'est pas fonctionnel : tous les liens vers les assets sont cassés (/assets au lieu de /moi-aussi/assets). Définir STATIC_URL='/moi-aussi/assets/' ne semble pas résoudre ce pb.
Évidemment ça semblerait plus facile de faire un vhost, mais je préférerais m'en tenir à un sous-dossier pour l'instant. C'est l'occasion de débugguer la doc ! ;)
Hum, c'est pas si simple ^^
Si `WSGIScriptAlias /` alors le site web HTML à la racine est cassé (je ne m'en étais pas rendu compte tout de suite, bravo moi...).
Mais avec `WSGIScriptAlias /moi-aussi` ça ne fonctionne que si `URL_PREFIX` est non définit (ie. *pas* `moi-aussi/`), et même ainsi, c'est pas fonctionnel : tous les liens vers les assets sont cassés (`/assets` au lieu de `/moi-aussi/assets`). Définir `STATIC_URL='/moi-aussi/assets/'` ne semble pas résoudre ce pb.
Évidemment ça semblerait plus facile de faire un vhost, mais je préférerais m'en tenir à un sous-dossier pour l'instant. C'est l'occasion de débugguer la doc ! ;)
Question intéressante, et je veux bien filer un coup de main, mais je préfèrerais qu'on ne fasse pas toutes les discussions dans le même ticket, par souci de clarté, tu ouvrirais un nouveau ticket pour ça ?
> Quant à la conf Apache, FWIW : […]
Question intéressante, et je veux bien filer un coup de main, mais je préfèrerais qu'on ne fasse pas toutes les discussions dans le même ticket, par souci de clarté, tu ouvrirais un nouveau ticket pour ça ?
Je vais peut-être essayer depuis une nouvelle branche...
PS: tu as bien généré une SECRET_KEY placée dans ton local.py ?
Oui
tu ouvrirais un nouveau ticket pour ça ?
OK
> certain que depuis la page https://code.ffdn.org/FFDN/wifi-with-me/pulls le bouton est grisé ? :-/
Yep : https://i.imgur.com/PpwLpyG.png
Je vais peut-être essayer depuis une nouvelle branche...
> PS: tu as bien généré une SECRET_KEY placée dans ton local.py ?
Oui
> tu ouvrirais un nouveau ticket pour ça ?
OK
Bon ben je sais pas quoi faire de plus. J'ai créé une branche pr1 où j'ai committé une bricole. Ce commit n'est pas ajouté à la liste de ceux du PR 57, et pourtant je ne peux toujours pas créer de nouveau PR (bouton grisé).
Toi tu peux pas merger ce PR, le clore une bonne fois pour toute (quitte à reverter ensuite), histoire de voir si ça va mieux après ?
Bon ben je sais pas quoi faire de plus. J'ai créé une branche [pr1](https://code.ffdn.org/Intarnet/wifi-with-me/commits/pr1) où j'ai committé une bricole. Ce commit n'est pas ajouté à la liste de ceux du PR 57, et pourtant je ne peux toujours pas créer de nouveau PR (bouton grisé).
Toi tu peux pas merger ce PR, le clore une bonne fois pour toute (quitte à reverter ensuite), histoire de voir si ça va mieux après ?
Bon ben je sais pas quoi faire de plus. J'ai créé une branche pr1 où j'ai committé une bricole.
Si je comprends bien la logique gogs, il faut que tu ailles sur la page de ton dépôt « source », et que tu cliques sur le petit bouton vert avec l'icône de pull request.
Toi tu peux pas merger ce PR, le clore une bonne fois pour toute (quitte à reverter ensuite), histoire de voir si ça va mieux après ?
Non pas trop chaud pour mettre le bazar sous le prétexte que le fonctionnement de gogs est défaillant ou qu'on ne l'a pas bien compris, j'espère que tu me comprendras :-). Donc je te propose que l'on essaye de faire ça correctement :-)
> Bon ben je sais pas quoi faire de plus. J'ai créé une branche pr1 où j'ai committé une bricole.
Si je comprends bien la logique gogs, il faut que tu ailles sur la page de ton dépôt « source », et que tu cliques sur le petit bouton vert avec l'icône de pull request.
https://screenshots.firefox.com/5p1l6kipxLGe3hTB/code.ffdn.org
Ça fonctionne ça ?
> Toi tu peux pas merger ce PR, le clore une bonne fois pour toute (quitte à reverter ensuite), histoire de voir si ça va mieux après ?
Non pas trop chaud pour mettre le bazar sous le prétexte que le fonctionnement de gogs est défaillant ou qu'on ne l'a pas bien compris, j'espère que tu me comprendras :-). Donc je te propose que l'on essaye de faire ça correctement :-)
Running
./manage.py migratewas failing (ImportError: No module named 'debug_toolbar') until I installeddjango-debug-toolbarPIP module.@MathieuMD whou, ça fait plaisir une contrib bien sentie, merci :-).
J'ai juste 2 remarques avant de merger :
En prod, django_debug_toolbar n'est pas utilisée… et il serait dangereux qu'elle le soit par accident.
ALLOWED_HOST*S*(« S » oublié)SITE_URLdevrait être dans la section "mandatory settings" (c'est moi qui l'avait mal rangé, mais puisque tu es dans les améliorations de cette partie… :p)Je me rend compte que la gestion des différentes confs n'est pas très claire (settings/prod.py settings/dev.py) ni bien documentée, désolé :x
C'est noté pour
ALLOWED_HOSTSetSITE_URL.Effectivement, je ne suis pas sûr d'avoir compris comment on passe du dev à la prod. Mais c'est peut-être parce que je ne connais pas du tout Django... En tout cas, ça mériterait quelques clarifications, oui ! :p
Peut-être que je manque quelque chose, mais sans ajouter
django_debug_toolbardansbase.txt, la toute première étape d'installation (./manage.py migrate) échoue :PS : j'ai déménagé le dépot de MathieuMD vers Intarnet : je vais refaire une PR depuis là-bas.
Dans le cas d'une installation en environnement de dév, tu dois faire un pip install -r requirements/dev.txt
Est-ce que tu peux l'ajouter à la doc ?
Une fois ta PR mergées, je m'appliquerais à compléter pour qu'on puisse bien comprendre cette histoire d'environnements de dév/prod etc…
Installer l'outil ne devrait pas requérir de connaître django.
J'ai poussé quelques commits de plus sur le dépot https://code.ffdn.org/Intarnet/wifi-with-me/commits/master, qui sont bien pris en comptes dans ce PR, bien que ses liens référencent toujours l'ancien propriétaire MathieuMD, et sont donc cassés. :-/
Dis-moi si je dois faire quelque chose différemment.
Ça c'est bien indiqué dans ta doc[1], pas de pb. Le problème c'est qu'il faut aussi jouer l'étape
migrateaussi en prod (non ?), et c'est elle qui ne passe pas sans installerdjango_debug_toolbar.Salut,
Merci de te donner ce mal en dépit d'une mauvaise doc :-x.
En fait, toutes les commandes qui commencent par
./manage.py, quand elles sont utilisées en prod, doivent-être préfixées de la sorte :(et ça, c'est complètement non documenté je crois :-x).
Sans ce préfixe (var. d'environnement), c'est les paramnètres de développement qui s'appliquent.
Les différents environnements (prod/dév/test) apportent des configurations par défaut utiles à ces environnements, pour le dév, envoyer les mails dans la console, activer le debug, pour la prod, désactiver le debug, configurer les logs correctement, et empêcher le service de démarrer si la secret key n'est pas générée.
Il faut que tu ouvre une nouvelle PR dont l asource est Intarnet/master. En effet, gogs ne permet pas de changer la branche source d'une PR une fois qu'elle est créée.
C'est ce que j'avais voulu faire, mais le bouton « Nouvelle Pull Request » était inactif, grisé (vert-de-grisé ?), bien que cette PR 57 était fermée, et je me suis rendu compte que mes nouveaux commits, faits sur le dépôt Intarnet, avaient été ajoutés à cette PR.
Peut-être que toi tu peux supprimer cette PR, pour que je puisse en faire une nouvelle avec les mêmes commits ?
Pour avoir une prod qui marche (merci pour le
DJANGO_SETTINGS_MODULE=wifiwithme.settings.prod ./manage.pyje l'aurais pas trouvé tout seul avant d'avoir pas mal vieilli ;)) j'ai du bricolerwifiwithme/wsgi.py:C'est peut-être pas très propre, mais j'ai pas trouvé mieux (sans, il braillait à cause du
SECRET_KEYmanquant). C'est d'ailleurs ce qui semble être conseillé par la doc Django, si je comprends bien.Ça serait bien d'expliciter ça aussi, dans la partie dev vs. prod (ou de dire ce qu'il faut configurer d'autre, si ça c'est crado)
Quant à la conf Apache, FWIW :
Je suis preneur de suggestions ! :D
certain que depuis la page https://code.ffdn.org/FFDN/wifi-with-me/pulls le bouton est grisé ? :-/
Je ne peux pas faire quoi que ça soit de plus que toi (c'est à dire avec des droits admin) qui faciliterait le truc à mon avis.
Ah, c'est bien vu, it's a bug ! Par contre utiliser setdefault me semble mieux (ça permet à quelqu'un qui souhaiterait surcharger ce paramètre de le faire). Tu ajouterais cette modif à ta PR ?
PS: tu as bien généré une
SECRET_KEYplacée dans ton local.py ?Hum, c'est pas si simple ^^
Si
WSGIScriptAlias /alors le site web HTML à la racine est cassé (je ne m'en étais pas rendu compte tout de suite, bravo moi...).Mais avec
WSGIScriptAlias /moi-aussiça ne fonctionne que siURL_PREFIXest non définit (ie. pasmoi-aussi/), et même ainsi, c'est pas fonctionnel : tous les liens vers les assets sont cassés (/assetsau lieu de/moi-aussi/assets). DéfinirSTATIC_URL='/moi-aussi/assets/'ne semble pas résoudre ce pb.Évidemment ça semblerait plus facile de faire un vhost, mais je préférerais m'en tenir à un sous-dossier pour l'instant. C'est l'occasion de débugguer la doc ! ;)
Question intéressante, et je veux bien filer un coup de main, mais je préfèrerais qu'on ne fasse pas toutes les discussions dans le même ticket, par souci de clarté, tu ouvrirais un nouveau ticket pour ça ?
Yep : https://i.imgur.com/PpwLpyG.png
Je vais peut-être essayer depuis une nouvelle branche...
Oui
OK
#58 Installation en sous-dossier
Bon ben je sais pas quoi faire de plus. J'ai créé une branche pr1 où j'ai committé une bricole. Ce commit n'est pas ajouté à la liste de ceux du PR 57, et pourtant je ne peux toujours pas créer de nouveau PR (bouton grisé).
Toi tu peux pas merger ce PR, le clore une bonne fois pour toute (quitte à reverter ensuite), histoire de voir si ça va mieux après ?
Si je comprends bien la logique gogs, il faut que tu ailles sur la page de ton dépôt « source », et que tu cliques sur le petit bouton vert avec l'icône de pull request.
https://screenshots.firefox.com/5p1l6kipxLGe3hTB/code.ffdn.org
Ça fonctionne ça ?
Non pas trop chaud pour mettre le bazar sous le prétexte que le fonctionnement de gogs est défaillant ou qu'on ne l'a pas bien compris, j'espère que tu me comprendras :-). Donc je te propose que l'on essaye de faire ça correctement :-)
Bien vu ! → #59 :)