# 30 ans de Python et une popularité croissante

Par Alexis Richter

La première version de Python (0.9.0) fut déployée le 20 février 1991, en Open Source, même si le terme « Open Source » n’avait pas encore été défini à l’époque. Dans ce billet, Alexis Richter, développeur Python et lead tech chez Atol CD, revient sur l’histoire du langage qui fête aujourd’hui ses 30 ans ! 

Lire le billet : https://blog.atolcd.com/30-ans-de-python-et-une-popularite-croissante/ 

# Modèle économique et Open Source (ou presque)

par Xavier Calland

Nous vous en parlions en début d’année avec le changement de licence d’ElasticSearch, le monde de l’Open Source subit des remous avec le changement de licences de certains projets. Cela met en évidence les difficultés de certaines entreprises de trouver un modèle économique viable alors que leur activité repose sur un produit Open Source.

Pour compléter la lecture et la compréhension du sujet, nous vous partageons deux autres liens :

# Gradle 7.0-RC1 améliore encore la gestion des dépendances

par Thomas Broyer

Près d’un an et demi après la version 6, Gradle, Inc. a publié une première release candidate de la version 7 de son outil de build. Comme pour toutes les versions majeures, ils s’autorisent à casser la compatibilité en supprimant des APIs précédemment dépréciées. Mais au menu de cette version 7, en plus d’améliorations de performances, du support de Java 16 et de la nouvelle puce Apple M1, et de la mise à jour vers Groovy 3; on trouve, en preview, une nouvelle fonctionnalité qui était en préparation depuis plusieurs mois (et plusieurs fois repoussée) : une déclaration centralisée des dépendances et de leur version, notamment dans un fichier au format TOML.

L’intérêt d’une telle centralisation paraît assez évidente (et vient remplacer tout un ensemble de pratiques et plugins qui s’étaient développés ces dernières années pour répondre à ce besoin), mais l’utilisation (optionnelle) d’un format de fichier déclaratif (plutôt que les scripts Groovy ou Kotlin permettant de définir le build) permet d’une part de les partager facilement entre les projets en allant jusqu’à les publier dans un repository Maven, et d’autre part de s’intégrer à des outils de mise à jour automatique des dépendances, du type Dependabot.

Ce fichier ne représente par contre que des contraintes sur les versions, à l’instar des package.json de NPM et autres Gemfile ou requirements.txt pour RubyGems et Python PIP respectivement, et pas les versions réellement utilisées dans le build. Celles-ci peuvent être enregistrées dans des fichiers verrous (dont le format évolue aussi dans cette version 7), similaires aux package-lock.json ou Gemfile.lock, depuis la version 4.8 il y a bientôt 3 ans, et leurs checksums et/ou signatures cryptographiques dans un fichier verification-metadata.xml depuis la version 6.2.

Couplés à la notion de variantes, de capabilities, de contraintes, qui peuvent être regroupées dans des plateformes, Gradle a à ce jour le système de gestion de dépendance le plus avancé de tous les outils de builds que je connais !

Tweetez
Partagez
Partagez
0 Partages