django est concerné.

On tombait dessus généralement assez tard, à la mise en prod, avec un message cryptique:

 
BlockingIOError: [Errno 11] Resource temporarily unavailable 
  
 The above exception was the direct cause of the following exception: 

Traceback (most recent call last): 
   .... <- des imports de votre code qui ne font rien de mal
   File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 36, in  
     import email.parser 
   File "/usr/local/lib/python3.6/email/parser.py", line 12, in  
     from email.feedparser import FeedParser, BytesFeedParser 
   File "/usr/local/lib/python3.6/email/feedparser.py", line 27, in  
     from email._policybase import compat32 
   File "/usr/local/lib/python3.6/email/_policybase.py", line 9, in  
     from email.utils import _has_surrogates 
   File "/usr/local/lib/python3.6/email/utils.py", line 28, in  
     import random 
   File "/usr/local/lib/python3.6/random.py", line 742, in  
     _inst = Random() 
 SystemError:  returned a result with an error set 

Cela a été corrigé rapidement, et le binaire patché ajoute juste un “+” à sa version:

$ python --version
Python 3.6.0+

En théorie vous ne pouvez pas tomber dessus, tous les liens de téléchargement ont été mis à jour, les distributions ont changé leurs dépôts, etc.

Mais hier je me suis fait bien niqué, et j’ai perdu 1h à debugguer cette surprise qui n’avait aucun sens (puisque mon code allait bien) : les bugs dans les binaires officiels sont rares et c’est le dernier endroit où je cherche.

En effet, certaines sources non-officielles pour installer Python n’ont pas été mises à jour, et c’est le cas du très populaire PPA deadsnakes.

Si vous avez installé Python 3.6 en faisant :

sudo add-apt-repository ppa:fkrull/deadsnakes
sudo apt-get update
sudo apt-get install python3.6

vous l’avez dans le cul.

Il existe un PPA plus à jour si vous avez besoin de corriger le tir :

sudo add-apt-repository ppa:jonathonf/python-3.6
sudo apt-get update
sudo apt-get install python3.6

Donc si vous avez compilé Python à la main ou utilisé un PPA, assurez-vous bien d’avoir la bonne version, et sinon upgradez. En attendant j’ai un bug report à faire à deadsnakes…

Mon rapport était incomplet, et on m’a demandé plus d’informations. J’ai pris du temps, mais j’ai répondu.

Malheureusement à la deuxième demande d’informations, j’ai trainé la patte. Je l’ai mis dans ma todo list, et ai regardé en chien de fusil l’entrée pendant des mois.

Il fallait réinstaller nuitka, me replonger dans ce que je voulais faire à l’époque, lancer la compilation, répondre sur le bug tracker. Une heure dépensée au moins.

C’est ça dont les gens ne se rendent pas compte : participer à l’open source, ou à un quelconque effort collectif, ça prend énormément de temps. Entre les interruptions que ça génère, l’historique qu’il faut remonter à chaque fois, le changement de contexte, et bien entendu l’activité elle-même.

Donc, quand on vous rapporte un bug, même de manière énervée, bénissez le Dieu de la procrastination que la personne ait pris le temps de le faire. Vous ne vous devez rien l’un à l’autre, et c’est un beau moment de synergie humaine.

En l’occurrence, donc, mon interlocuteur a fini par marquer le bug comme “lack of feedback”.

D’un certain côté, ça m’a soulagé, je n’avais plus du tout envie de m’y remettre.

D’un autre côté, j’ai culpabilisé, me disant que quand même, j’utilise du FOSS, faudrait contribuer plus, et que j’avais fais perdre du temps à l’auteur.

Au final, cette semaine, je reçois une notification comme quoi une autre personne a continué le fil : il a le même problème.

J’avais oublié ce détail : en prenant le temps d’ouvrir un fil de discussion, je lui avais donné vie. Je lui avait donné une légitimité. Et il se trouve qu’avec les infos fournies par le nouvel arrivant, le ticket a été marqué en bug, et sera corrigé.

C’est un effort collectif, et même si je n’ai pas fais autant que ce que j’aurais voulu, j’ai joué mon rôle. Un rôle imparfait, mais utile.

Donc souvenez-vous : reportez vos bugs, il en restera toujours quelque chose.

On a parfois du mal à localiser l’origine d’un bug dans une longue requête sql ou un code spaghetti de 5000 lignes écris en 1999 par un biologiste recruté dans une SSII. Bien sur vous pouvez tenter la méthode traditionnelle, essayer de comprendre d’où viens le bug, de façon logique… ou bien gagner du temps et appliquer la méthode que je préfère dans ce genre de situation : la dichotomie.

Le principe est simple, couper en deux le code défectueux (commenter la moitié), re-faire un test, si le code marche, l’erreur viens de la partie commentée ou inversement, ensuite prenez la partie défectueuse et recommencez. Vous tomberez assez rapidement sur le bug, généralement en quelques minutes grand max, sans avoir réfléchi, c’est pratique quand vous devez trouver un bug rapidement en prod dans la panique générale.