Django rest framework : Got AttributeError when attempting to get a value for field `my_field` on serializer `UserSerializer`.

Si vous voulez faire un mapping avec un modèle c’est ultra simple. Si vous voulez ajouter un champ custom, là ça devient compliqué…

Aucune réponse viable sur stackoverflow, vous risquez de chercher longtemps.

Si vous avez fait un code comme cela, pour rajouter un champ « custom » :

class UserSerializer(serializers.ModelSerializer):
    my_field = serializers.CharField(allow_blank=True)
    class Meta:
        model = User
        fields = ['url', 'email', 'password', 'my_field']

Eh bien cela ne marchera jamais, avec une erreur qui ne vous met absolument pas sur la voie :

Got AttributeError when attempting to get a value for field `my_field` on serializer `UserSerializer`.
The serializer field might be named incorrectly and not match any attribute or key on the `User` instance.
Original exception text was: 'User' object has no attribute 'my_field'.

Voici la solution : autoriser le null :

class UserSerializer(serializers.ModelSerializer):
    my_field = serializers.CharField(allow_blank=True, allow_null=True)
    class Meta:
        model = User
        fields = ['url', 'email', 'password', 'my_field']

git : exemple de fichier

Voici un exemple de fichier de configuration qui ignore la plupart des fichiers qui posent problème :

# --------------------------------------
# git cleanup if too many files / or / problems:
# git reflog expire --expire=now --all && git repack -ad && git prune
# --------------------------------------
# PyCharm
.idea/
# --------------------------------------
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
# --------------------------------------
# C extensions
*.so
# Distribution / packaging
bin/
build/
develop-eggs/
dist/
eggs/
lib/
lib64/
parts/
sdist/
var/
*.egg-info/
.installed.cfg
*.egg
# --------------------------------------
# Installer logs
pip-log.txt
pip-delete-this-directory.txt
# --------------------------------------
# Unit test / coverage reports
.tox/
.coverage
.cache
nosetests.xml
coverage.xml
# --------------------------------------
# Translations
*.mo
# --------------------------------------
# Mr Developer
.mr.developer.cfg
.project
.pydevproject
# --------------------------------------
# Rope
.ropeproject
# --------------------------------------
# Django stuff:
*.log
*.pot
# --------------------------------------
# Sphinx documentation
docs/_build/
# --------------------------------------
# git
objects/
# --------------------------------------
# swap files
*.swp
*.swo

Bootstrap : classes utilitaires

Vous allez peut-être trouver du code qui ressemble à cela :
<p class="mb-0">Texte dans un paragraphe</p>

Bootstrap >= 4 a mis en place plein de possibilités pour faire du padding et des marges « responsives ».
Elles fonctionnent pour tous les breakpoints :

  • xs (<=576px)
  • sm (>=576px)
  • md (>=768px)
  • lg (>=992px)
  • xl (>=1200px)

<p class="{propriété}{côtés}-{taille}">texte</p>

propriété :

  • m – les marges
  • p – le padding

côtés :

  • tmargin-top or padding-top
  • bmargin-bottom or padding-bottom
  • lmargin-left or padding-left
  • rmargin-right or padding-right
  • x*-left and *-right
  • y*-top and *-bottom
  • blank – les 4 côtés à la fois

taille :

  • 0 – supprimer les marges ou mettre le padding à 0
  • 1 – $spacer *0.25
  • 2 – $spacer *0.5
  • 3 – $spacer
  • 4 – $spacer *1.5
  • 5 – $spacer *3
  • auto – margin à auto

Python : faire un « beep » sur Debian

Le code est simple, il fautt avoir paplay d’installé (je ne sais pas si c’est installé par défaut dans Debian).

A partir de là voici un exemple de code qui joue un fichier ogg :

# python3
>>> import subprocess
>>> subprocess.Popen([
... "paplay",
... "/home/olivier/.local/blah/Mission_Failed.ogg"
... ]).poll()
>>>

Sublime Text : licence. Oui. Licence.

Oui.

TAX INVOICE

TAX INVOICE? One image:

Run away!

Je l’ai fait. OUI.
Sublime Text licence bought

J’ai même choisi toutes les catégories dans lesquelles il peut entrer :

  • développement
  • développement divers
  • développement Internet
  • développement Django
  • Php
  • programmation C
  • programmation JavaScript
  • Python
  • geek
  • gestion de projet
  • euh j’arrête, il peut entrer… partout ! (aucune digression, merci !)

Je lutte activement contre la mentalité Française latine : j’essaie d’expliquer à tout le monde qu’il faut arrêter de scier la branche sur laquelle on (= les développeurs) est assise : si vous pouvez avoir quelque chose de gratuit, mais que vous vous en servez souvent, faites le calcul : s’il vous fait économiser du temps, donc de l’argent, bah la conclusion est simple : il faut que cela continue. Pour que cela continue, payez (moins que ce qu’il vous a fait économiser, sinon c’est pas intéressant) mais payez, bon sang !

J’ai évolué de ce côté et je fais tout pour que les personnes que je fréquente – et étudiants – aillent dans ce sens.

Donc oui, Sublime Text me fait gagner du temps tous les jours depuis plusieurs années, et aujourd’hui, la conclusion est évidente : il m’a fait gagner bien plus que 80 €.

Donc… je résume, une image vaut mille mots. Et même si pour certains c’est vieux, le principe reste éternel :

Anastacia - I paid my dues

PS : pour ceux qui ne savent pas ce que « OMFG » signifie, ne le dites à personne, et allez vite chercher sur Internet. Promis on ne le dira à personne. C’est comme « RTFM ». Promis.

python, flask, https et wsgi howto

Je ne vais pas dire le temps que j’ai passé à réussir à mettre ça en oeuvre si quelqu’un fait ça en quelques minutes j’aurais honte… mais disons que j’ai passé beaucoup de temps à le faire tourner, mais je suis vraiment impressionné par sa rapidité. Voici – via ma petite expérience – comment faire tourner un serveur Web très optimisé, en mode production  :
  • flask
  • wsgi
  • https

https / certbot

Je vous donne des pistes, à vous de finir.
L’idée, c’est que je veux paramétrer pour la n-ième fois un nouveau nom de domaine via certbot, et je ne veux pas qu’il touche à la conf de nginx. L’idée c’est que :
(1) Je le fais simplement via certbot-auto puis après,
(2) toutes les autres fois j’utilise « -d » pour qu’il ne touche pas à la conf, et je le fais à la main, en m’inspirant de la conf que cert-bot a fait dans le (1)
Donc, pour faire le (1), je demande à certbot de me créer uniquement le certificat : ./certbot-auto certonly -d monsite.fr
Pour le https, regardez ici.

Python

Code exemple, qui lit un fichier JSON, lance le serveur et sert le fichier lu en tant que JSON :

import json

from flask import Flask, jsonify

app = Flask(__name__)

with open("mon fichier JSON", 'r') as f:
    json_levels_full_description = json.load(f)


@app.route('/')
def index():
    return jsonify(json_levels_full_description)

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8004)
else:
    application = app

Attention : surtout ne faites pas le classique if __name__ == '__main__' car uwsgi inclut ce fichier, donc ce fichier n’est jamais un __main__, par contre la configuration au lancement a besoin d’une variable globale nommée application.

Nginx

Je copie colle la configuration d’un site qui tourne déjà en https, en voici un extrait diminué à mort pour ne pas polluer avec des règles personnelles, regardez bien le texte en gras, c’est le plus important pour faire tourner Nginx en collaboration avec wsgi :

server {
  server_name "~(www\.)?monsite\.(com|fr|org|biz|be)$";

  index index.html index.htm;

  access_log /blah/proxy-access.monsite.log proxylog;
  error_log /blah/proxy-error.monsite.log error;

  listen 443 ssl;
  ssl_certificate /blah/fullchain.pem;
  ssl_certificate_key /blah/privkey.pem;
  include /blah/options-ssl-nginx.conf;
  ssl_dhparam /blah/ssl-dhparams.pem;

  location / {
    include denied_clients;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Server $host;

    # (!) here it's uwsgi:
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:8002;

  }
}

# redirect http -> https:
server {
  listen *:80;
  server_name "~^monsite\..*$";
  return 302 https://$host$request_uri;
}

Flask

Pour installer flask, et uwsgi, faites un environnement virtuel puis installez les deux :

$ python3 -m venv venvpython.3.6.6
$ source venvpython.3.6.6/bin/activate
$ pip install --upgrade pip
$ pip install flask

uwsgi

Il faut être dans le venv activé (voir paragraphe précédent), puis l’installer via pip :

$ pip install uwsgi

Enfin, le script de lancement !

uwsgi --chdir=/web/htdocs/blah \
    --module=flask_server:application \
    --master --pidfile=/tmp/uwsgi.blah.pid \
    --socket=127.0.0.1:8004 \
    --processes=5 \
    --uid=1000 --gid=2000 \
    --harakiri=20 \
    --max-requests=5000 \
    --vacuum \
    --home=/web/htdocs/blah/venvpython.3.6.6

flask_server correspond au fichier python flask_server.pydécrit dans la section python au début et application est le nom de la variable globale (lisez le code de la section python)

Lorsque vous le lancerez, tout se passera bien, mais l’exécutable ne sera pas en tâche de fond. Cela a un avantage : un CTRL-C et vous l’arrêtez ! L’inconvénient, c’est que vous n’avez pas la main.

Si vous voulez le lancer en tâche de fond et qu’il écrive les logs dans un fichier, ajoutez l’option     --daemonize=/var/log/uwsgi/blah.uwsgi.log


Notes d’amélioration :
– Le port 8004 peut être passé en tant que variable d’environnement à l’application flask via le paramètre `env` de la commande uwsgi, ce qui rend le code plus portable ;
– Les paramètres uwsgi peuvent être consignés dans un fichier my_app.ini et uwsgi serait alors lancé en faisant uwsgi my_app.ini

Linux prompt how-to customisé + explications

Je vais faire un résumé de ce que j’ai trouvé un peu partout, et pourquoi j’ai choisi mon prompt tel que je l’ai fait.

  1. Visuellement, avoir quelque chose de coloré est extrêmement parlant. Il me fallait absolument utiliser les couleurs possibles du prompt pour rapidement mettre en évidence ce qui m’intéresse ;
  2. Le bash a sa syntaxe qui est très efficace mais pas forcément facile à appréhender ;
  3. Comme pour tout ce qu’on cherche sur Internet en termes de développement, il y a à boire et à manger… et cela semble devenir vrai aussi pour Linux. J’espère vraiment (x 450e+6654) me tromper.

Ce que j’ai trouvé et qui fonctionne selon mes tests. Ici, bien sûr, peut être qu’il y a d’autres solutions, mais celle que je donne ici a fonctionné sur tous les shells que j’ai testé (Ubuntu, Mint mais aussi CentOS).

Séquence invisible

Toute séquence qu’on ne veut pas visible doit être entourée par \[ et \].
Fin de l’histoire. Je vais pas pleurer en disant que j’ai passé un sacré paquet de temps à trouver ça alors que c’est très simple. Ah si je pleure ? Bon ok.

Changer de couleur

Pour changer de couleur, il faut imaginer qu’on change simplement de stylo. Simple, me direz-vous ? Mais après avoir lu et travaillé dans le Web où on ouvre puis on ferme une balise, ici, non. Il faut envoyer une séquence spéciale : \033 puis ouvrir un crochet qu’on ne va pas fermer, c’est codé en dur, il faut l’accepter tel quel : [. Et ensuite, un chiffre : 0 pour dire qu’on veut une couleur foncée, ou 1 pour dire qu’on la veut un peu plus claire (ex : le noir devient gris) puis un point virgule ;. Ensuite, il faut donner un chiffre compris entre 30 et 36 pour préciser la couleur. Et vous croyez que c’est terminé ? Non ! Il faut terminer par la lettre m. Si vous avez bien lu, vous devriez instantanément comprendre l’exemple suivant : \[\033[1;31m\]. Oui oui, le crochet au milieu ne se ferme jamais. Respirez, calmez-vous. C’est la vie. Il faut faire avec.

Pour toutes les couleurs, j’ai tout mis dans mon mémo qui remplace ma mémoire trop remplie (je préfère dire « trop remplie » que « défaillante », mais parfois j’hésite entre les deux…).

Restorer la couleur d’origine

Oui c’est en h1 parce que c’est aussi important que les deux paragraphes précédents : pour restaurer la couleur d’origine, cela ressemble un peu à l’ordre précédent : entourer par des crochets échappés, une séquence de couleur qui n’a pas deux valeurs mais une seule : 0. Cela donne : \[\033[0m\].
Donc votre code qui change votre prompt devrait toujours se terminer par « remettre la couleur d’origine », soit \[\033[0m\]. Ce n’est que mon point de vue…

Mon prompt

Vous allez me dire « mais pourquoi il fait tout un article sur un prompt ? ». Réponse : c’est comme mon clavier : j’ai passé beaucoup de temps à l’apprendre et le configurer, parce que je sais que sur du long terme ça va m’être très rentable. Passer plusieurs semaines pour gagner plusieurs mois, ça vaut le coup, fin de l’histoire. Donc, voici ma réflexion qui explique mon choix de prompt. J’aurais tout autant pu vous répondre un grand classique indétrônable : le diable est dans les détails.

  1. J’ai très souvent besoin de savoir globalement l’heure qu’il est. J’aimerais bien, dans mon prompt, je sache l’heure qu’il est. Si je tape quelque chose, je valide, hop j’ai la nouvelle heure. Pratique, pas « mortellement pratique », mais sympa. De plus, 6 caractères utilisés pour HH:MM[espace] c’est négligeable. Par contre, j’aimerais que visuellement, ça ne soit pas polluant. C’est pratique, mais pas important. La couleur la plus sombre possible dans le prompt c’est « noir éclairci », soit premier chiffre = éclairci = 1 et second chiffre = noir = 30. Donc mon premier ordre c’est « noir éclairci + heure », donc : \[\033[1;30m\]\t 
  2. La seconde chose, qu’on retrouve partout, c’est bien sûr, qui est connecté, donc l’utilisateur. Là, ça devient plus important. Mais pas le plus important pour moi (surtout sur la fin du prompt où on voit en méga surbrillance, si on est superuser ou utilisateur normal) : c’est une couleur foncée 0 et qui peut avoir un pendant « éclairci » plus agréable pour préciser l’hôte (j’en parle juste après) : j’ai choisi purple = 35. La séquence échappée du user en cours est \u. Ici aussi, si vous avez suivi, ça donne, couleur + user en cours : \[\033[0;35m\]\u
  3. Ensuite, séparateur entre l’utilisateur et l’hôte. Le classique « @ » qui ne doit pas être gênant, même couleur que l’heure : « noir éclairci », soit \[\033[1;30m\]@
  4. L’hôte. Oui, le grand classique c’est «[userconnecté]@[hôte]», et si des millions de geeks linux ont choisi cela c’est que c’est parlant. Mais ici, comme je gère pas mal de machines, selon moi, il faudrait que l’hôte soit un peu plus visible que le user en cours. Donc même couleur que le user, mais avec «1» au lieu de «0». Sachant que la séquence échappée de l’hôte est \h on obtient : \[\033[1;35m\]\h
  5. Avant dernière chose (pour moi) : le path. Là, bon sang, il faut que ça pète. Il faut que le yeux le voient même si on commence à s’endormir (petit clin d’œil à ceux qui mangent kebab-frites avant de commencer les cours avec moi). Un bon rouge, bien éclairci. Allez on le fait rapide : pour exécuter un ordre à chaque appel de prompt, l’astuce est d’échapper le $ et de mettre entre parenthèses l’ordre shell qu’on veut lancer : ici, on est sur du Linux, c’est instantané. La solution, donc : rouge vif + $(pwd) version « échappée » :
    \[\033[1;31m\]\$(pwd)
  6. Dernière information : la plus cruciale, toujours présente sur tous les paths : quel type d’utilisateur est connecté : \$. Il est substitué par # si vous êtes root, sinon $. Là, il faut qu’on ait les yeux qui brûlent. Lunettes de soleil. Du jaune, le plus visible possible (= « 1« ). Un bon jaune qui fait pleurer les yeux, mais ça ne prend qu’un caractère, qui est IMHO, d’une importance cruciale :
    \[\033[1;33m\]\$

Voici donc mon bash résumé en une ligne, que je mets dans tous mes .bashrc. Si vous ne savez pas ce qu’est un .bashrc, je vous laisse chercher, ce n’est pas le but de l’article.

Voici ce que donne mon prompt, et même si ici il n’est pas super vendeur, en pratique, je n’ai pas trouvé quelque chose de plus efficace visuellement parlant, si vous avez des idées / suggestions, améliorations, commme d’habitude, je suis preneur :

Mon prompt Linux shell

Le code de mon prompt, volontairement en minuscules juste pour vous faire râler :

export PS1="\[\033[1;30m\]\t \[\033[0;35m\]\u\[\033[1;30m\]@\[\033[1;35m\]\h \[\033[1;31m\]\$(pwd) \[\033[1;33m\]\$\[\033[0m\] "

PS : pour ceux qui ne savent pas ce que « IMHO » signifie, ne le dites à personne, et allez vite chercher sur Internet. Promis on ne le dira à personne. C’est comme « RTFM ». Promis. Chut. [silence gêné].

Django 2.1 : les autorisations de l’administration grandement facilitées

Voici le (petit) souci que tout le monde a forcément dès qu’on commence à vouloir un peu pousser la customization de l’administration Django : on aimerait avoir la possibilité d’accéder à certains modèles, mais uniquement en lecture seule. J’ai des tonnes d’exemples simples, mais très souvent, ce sont des modèles avec des choix « fixes » qui ne risquent pas d’évoluer dans le temps (exemple : sexe « féminin »/ »masculin »). Seulement (1) on ne veut pas le voir apparaître dans l’admin (2) si on ne veut pas le voir apparaître, il ne faut pas le déclarer, et Django ne veut pas accéder à un modèle qui n’est pas déclaré (= erreur), donc on en arrive toujours à (3) on déclare le modèle, on applique une solution « bidouille » que je ne décris pas ici mais même si le modèle n’apparaît pas dans l’interface, en tapant à la main la bonne URL (facile à deviner qui plus est), on peut tout de même modifier ce modèle. Heureusement la version 2.1 de Django pallie à ce manque !

Eh oui, dans la classe interne «Meta», ils ont fait évoluer default_permissions, qui est écrit en base. Donc en passant à Django 2.1 il vous faudra faire le fameux makemigrations migrate.

Là ou cela devient intéressant, c’est que dans les options vous avez default_permissions et elles sont ('add', 'change', 'delete', 'view'). Le plus important et le nouveau est donc 'view' qui pallie parfaitement au problème expliqué en haut !

Il vous suffit de déclarer votre modèle, de faire la classe dérivée de ModelAdmin et de préciser uniquement ('view',).
Attention, je n’ai pas testé, si quelqu’un veut tester et confirmer que ce code fonctionne (ou pas), je suis preneur !

class SexeAdmin(models.ModelAdmin):
    class Meta:
        default_permissions = ('view',)

Plein de code en moins, plus aucune bidouille ici, plus de lisibilité, bref, de mieux en mieux !

Django Async Roadmap

Petite parenthèse sur l’évolution de Django. Aujourd’hui, ce qui commence à importer plus que la vitesse, c’est la parallélisation des choses.
Donc avoir un serveur Web asynchrone, c’est censé être mieux qu’un serveur Web synchrone (= bloquant).

  • Django 2.1 : rien d’asynchrone. Aucun travail dessus.
  • Django 2.2 : travail initial pour ajouter la possibilité de faire de l’asynchrone sur l’ORM et les vues, sachant que c’est une option et que tout sera synchrone par défaut. Le support async sera principalement basé sur des pools de threads.
  • Django 3.0 : Ré-écriture de la gestion interne des requêtes pour être 100% asynchrone, ajout de la gestion asynchrone des middleware, forms, cache, sessions, auth. Début du process de dépréciation pour toutes les APIs prévues pour être uniquement asynchrones.
  • Django 3.1 : amélioration du support async, peut-être changement du templating
  • Django 3.2 : Fin du process de dépréciation et Django sera presque entièrement asynchrone.

Django et git (git « pur », pas « github »)

Si jamais vous décidez d’être un vrai guerrier, un de ceux qui veulent tout maîtriser, un de ceux qui, quand on leur donne des ordres, peuvent les refuser (oui c’est rare), et si vous voulez prendre des responsabilités, bref, si vous en avez : faites vous votre propre serveur git !

Je ne décrirai pas comment installer un serveur git sous Linux tellement c’est simple. Et je ne décrirai pas non plus comment faire ça sous Windows : pour des raisons de sécurité, de fiabilité et d’éthique, évitez Windows un point c’est tout.

Donc, sous Linux :

  • Créez un dossier dans lequel vous mettez toutes vos sources (scp est votre ami si vous êtes sur un PC et que vous voulez faire cela sur un autre PC)
  • Supposons que l’on est dans /web/htdocs/interro/htdocs
  • Créez un fichier .gitignore
  • Dans ce fichier, mettez ceci :
    *.pyc
    __pycache__
    myvenv
    db.sqlite3
    /static
    .DS_Store

    Cela signifie « ignore tous ces fichiers (.DS_Store est pour les personnes sous Mac (non je ne vous en veux pas, je suppose que vous ne connaissez pas bien l’histoire de l’informatique pour avoir acheté Apple)) » pour toutes les personnes qui vont cloner ce dossier
  • Ensuite, ajoutez tous les fichiers ainsi : git add --all .
  • Et commitez (oui je sais ce n’est pas français) ou « appliquez » les modifications c’est à dire l’ajout de tous les fichiers ainsi : git commit -m "My application, first commit"
  • Vous devriez avoir un paquet de fichiers ajoutés, vérifiez que tout est bien enregistré en demandant l’état via git status. Vous devez avoir un messsage ressemblant fortement à
    nothing to commit (working directory clean)
  • Vous êtes prêts ! Vous avez crée un repository (j’ai la flemme de traduire en français), et vous y avez appliqué tous vos fichiers. Il ne vous reste plus qu’à le cloner à distance
  • (Update) : par défaut, le serveur travaille sur la branche d’origine (« master »). Seul problème : si vous essayez de faire un « push » à partir de votre PC de développement, git ne sera pas d’accord pour faire un « push » sur la branche « master ». Je pense que c’est pour des raisons de sécurité ou autre, mais c’est plutôt récent, avant cela fonctionnait. La solution : dites sur le serveur de travailler sur une autre branche c’est via l’ordre checkout. Notez bien : c’est sur le serveur. Je ne trouve pas ça très cohérent, j’aurais dit que c’était au client de dire sur quelle branche il veut « push », mais je dois manquer quelque chose… j’ai vraiment beaucoup de lacunes git. Bref. Exemple : git checkout -b development.
  • Ensuite il vous suffira de faire un git clone (dans PyCharm, c’est le menu VCS » git » clone)

Bien sûr, comme tous les gestionnaires de version délocalisés, il vous faudra toujours trois étapes pour valider vos modifications :

  1. Appliquer les modifications en local (git commit -m "mon message expliquant les modifs")
  2. Essayer de récupérer toutes les dernières modifications du repository (git pull) vers votre code « local », au cas où d’autres personnes auraient « pushé » des modifications
  3. Envoyer vos modifications sur le serveur pour qu’elles soient accessibles à tout le monde (git push)