Ecrire une librairie qui soit perenne ?

Salut,

- Comment écrire une librairie qui soit perenne que même des utilisateurs débutants pourront utiliser facilement sans trop de prises de tête notamment avec l'installation et les configurations ?

Je vois parfois des librairies qui ne fonctionnent pas car elles nécessitent la version 2 de python, est-ce que ce genre de problème peut encore arriver à l’avenir ? Et même d'une manière générale, est-il possible qu'une librairie qui fonctionne à une époque donnée avec une version de python donnée, ne fonctionne pas quelques années plus tard ?

Faut-il donc préciser la version de python dans son dépôt ? Les utilisateurs pourront-ils télécharger les anciennes versions ?

- Comment structurer son projet pour éviter le plus possible les prises de tête notamment avec l'installation et les configurations ?

Je vois que maintenant UV semble avoir la côte, si j'ai bien compris on peut tout automatiser (environnement virtuel avec la version de python souhaitée,...).

Merci.

Salut beginner.

Citation:

---

Envoyé par Beginner

Comment écrire une librairie qui soit pérenne ?

---

Oui, c'est possible mais dans ce cas, il faut utiliser un langage qui soit indépendant de toute version de Python et de votre environnement.
Par exemple en 'C".

Hello,

Concernant la rupture python 2 vers python 3, non, il est extrêmement improbable de revivre une telle fracture. La transition vers Python 3 était un changement de paradigme exceptionnel et nécessaire pour corriger des défauts fondamentaux du langage (notamment la gestion des chaînes de caractères et de l'Unicode). Le Python Steering Council (l'organisme qui dirige l'évolution du langage) a publiquement indiqué qu'un hypothétique "Python 4" n'introduirait pas de cassure de rétrocompatibilité d'une telle ampleur.

Par contre dans mon taf, j'ai des projets legacy encore en python 2.6-2.7 et donc concrètement oui, on peut encore avoir de très vieux projets avec ces versions, mais tous les nouveaux projets n'ont plus à être en version 2.x
Il peut arriver que certains projets ne fonctionnent plus, mais avec la containérisation (docker) il est rare de ne pas pouvoir faire revivre son projet legacy.

Python évolue régulièrement, il y a la PEP 387 qui permet de suivre une politique stricte de dépréciation. Si une fonctionnalité doit disparaître, elle émet un avertissement (DeprecationWarning) pendant au moins deux versions annuelles avant d'être supprimée.

Concernant le fait de préciser la version python, oui, c'est même obligatoire pour un projet professionnel. La norme actuelle (PEP 621) impose de déclarer la compatibilité dans un fichier unique nommé pyproject.toml via la clé requires-python (ex: requires-python = ">=3.9") et oui, les utilisateurs peuvent toujours télécharger et exécuter d'anciennes versions de Python. Les archives officielles de python.org conservent tout, et les outils modernes s'occupent d'aller les chercher automatiquement si nécessaire.

Vous avez parfaitement raison concernant uv. Développé par Astral (qui édite aussi Ruff), uv est en train de devenir le standard de facto car il est extrêmement rapide (écrit en Rust) et remplace à lui seul presque tous les anciens outils de gestion de projet (pip, venv, poetry, pyenv, etc.). Tout doit être centralisé dans le fichier standard pyproject.toml.

Petite astuce : si vous pouvez faire quelque chose avec la bibliothèque standard de Python, privilégiez-la plutôt que d'importer un paquet externe.

J'espère avoir répondu à toutes vos questions, en tout cas vous avez déjà pas mal de mots clé pour vous guider vers des renseignements demandant plus de précisions.