Le portage de buildez.pdb vers Python 3 a été terminé tardivement, entre 2023 et 2024, pour des raisons de dépendances vis à  vis d’outils et de toolkits chemo-informatiques, comme pour le reste des codes.  Ceci dit, les codes génériques de Pybuild-buildez ont été convertis assez facilement, ce qui n’est pas étonnant car il s’agit d’une programmation survivaliste.

D’après un article publié en 2023 sur buildez.net – Revu en Avril 2025.

1. Une programmation ‘survivaliste’

Ce qu’il faut entendre par la, c’est que l’écriture vient d’un langage ancien et est pensée pour s’adapter à  un langage futur. Avec trois règles: i) si quelque chose peut être écrit en 5 lignes au lieu d’une, il faut prendre l’option 5 et ii) si ce n’est pas possible, la fonctionnalité avancée du langage est cachée sous une fonction d’interface; iii) il ne sera jamais nécessaire de patcher un code maison, si c’est le cas il faut revenir au deux règles précédentes.

Ce type d’approche est souvent implémenté dans Python sous cette forme :

La fonction mylib est assimilable à  une interface, chaque version pouvant pouvant être incluse dans une bibliothèque différente et c’est Python qui gèrera si le code est utilisable. Mais en ce qui concerne les sous projets (ex: buildez.pdb ou buildez.chem) les dépendances vis à  vis de paquetages métiers étant trop complexes, la migration a du être menée globalement pour l’ensemble des codes.

2. Des codes tiers

Il est clair que buildez est dépendant d’outils tiers, qui présentent un risque: celui de ne pas évoluer : codes, bibliothèque et son interface … les aspects liés à l’utilisation de binaires sont importants pour Windows car la recompilation est souvent laborieuse. Ce type d’inquiétude était présent pour OpenBabel/Pybel (utilisé dans buildez.chem) ou Biopython (utilisé dans buildez.bio). A leur tour, des modules de buildez.chem.pybel_interface et de buildez.bio étaient utilisés par des modules de buildez.pdb. Donc il y a eu une opération de simplification destinée à implémenter les fonctionnalités équivalentes (code maison, autre code tiers, passage sur un fork du projet tiers comme PIL/Pillow).

Fonctions d’interface

L’idée est d’avoir des codes principaux très stables et des fonctions d’interface variables, sur lesquelles se concentrent les difficultés. Ce qui marche si l’architecture générale est saine et pensée pour offrir ce type de fonctionnement.
Pour donner une idée, coté chimie RDKit est venu s’ajouter à Pybel, les fonctions et les objets natifs de chaque toolkit sont différents, mais les fonctions d’interface qui les utilisent sont similaires. Par exemple, pour charger un fichier SDF et sauver les objets (Pybel ou RDKit) dans une liste Python, nous aurons :

# A partir du module rdkit_sdf.py  def rdkit_sdf2mols(where, verb=0): # A partir du module pybel_sdf def pybel_sdf2mols(infile):

Il suffira de changer le début de la fonction (pybel_ et rdkit_) et d’enlever l’argument optionnel, s’il est spécifié, à moins que je programme aussi dans la contre partie. Cela nécessite pas mal de travail en amont avant d’utiliser les composants, mais cet effort n’est pas perdu sur une longue durée.
Finalement, en 2020 je crois, OpenBabel/Pybel est passé en version 3, Biopython est également passé en version 3, ce qui a a permis d’éviter beaucoup de problèmes. Mais coté Chimie et MS Windows, des problèmes persistaient avec la depiction (2D) de molécules pour afficher des formules développées (colorées, bitmap, vectorielles). Mais en échange Cairo/PyCairo s’est stabilisée, l’installation (subtile) avec GTK n’était plus utile. D’ailleurs les autres paquetages tiers ont eu ce type de problèmes, par exemple OASA (affichage de formules développées basées sur Cairo) ayant stoppé en version Python 2, il à fallu une adaptation. De mon coté, j’ai quand même gardé OASA dans un coin, car il me permets d’avoir un accès au graphe moléculaire intéressant (bien que non finalisé).
Et ce qui était prévu déjà  vis à  vis de RDKit pourrait s’étendre à d’autres interfaces, pourquoi pas CDK, et/ou des produits plus difficiles d’accès (commerciaux).

3. A suivre …

Mais dans buildez.pdb les fonctions purement liées à la biologie structurale n’utilisent pas de code tiers, par exemple le parseur bio.PDB de Biopython, ce qui serait pourtant logique. Ce n’est pas pour une question de vitesse, mais pour l’accès aux données et surtout pour gérer explicitement les exceptions dans la PDB, qui concernent plus de la moitié des structures. Des fonctions essentielles dans l’hypothèse de requêtes automatisées et étendues à l’ensemble de la PDB.  Le changement de l’espace de noms build => buildez a également été finalisé sur les codes et la documentation.

4. Conclusion

J’assume ce type de programmation, elle me permet d’évoluer tout en gardant ce qui marche bien. Dans un paquetage non exposé destiné à  de l’optimisation non linéaire, des lignes fossiles sont issues de codes FORTRAN, BASIC, Modula2 … ce n’est pas neuf et cela donne une idée, mais pourquoi se passer d’un code incassable ? Au fur et à  mesure du temps, pour une fonctionnalité donnée, plusieurs fonctions d’interface peuvent exister ou disparaitre, avec des niveaux d’accélération et de performances (mais aussi de maintenance) différents. Ce qui n’est pas inutile pour tester les codes et vérifier les résultats. Ce qui n’est pas inutile, non plus pour générer des codes devant fonctionner sous différents OS.