Cela a tout de même ses limites : tu ne peux pas dire (comme avec apt) que le projet psycopg2-binary fournit le package psycopg :(
Ou alors il faut mettre psycopg comme dépendance de psycopg-binary (alors que c'est le contraire d'un point de vue logique).
Après, comme le packaging Python utilise un fichier setup.py (script Python comme un autre), tu peux déclarer des dépendances dynamiquement : par exemple, setup.py peut tester le système sur lequel le paquet est en cours d'installation et va déclarer des dépendances en fonction de la version de Python, des libs déjà installées, etc.
Cet avantage vient avec son inconvénient miroir : tu ne peux pas faire de l'analyse statique pour déterminer les dépendances (alors qu'avec un paquet apt, il suffit de lire un fichier de contrôle pour avoir toutes les dépendances).
[^] # Re: Comme psycopg2
Posté par flan (site web personnel) . En réponse au journal Retour d'expérience sur l'empaquetage d'une bibliothèque native pour Python. Évalué à 2.
Cela a tout de même ses limites : tu ne peux pas dire (comme avec apt) que le projet psycopg2-binary fournit le package psycopg :(
Ou alors il faut mettre psycopg comme dépendance de psycopg-binary (alors que c'est le contraire d'un point de vue logique).
Après, comme le packaging Python utilise un fichier setup.py (script Python comme un autre), tu peux déclarer des dépendances dynamiquement : par exemple, setup.py peut tester le système sur lequel le paquet est en cours d'installation et va déclarer des dépendances en fonction de la version de Python, des libs déjà installées, etc.
Cet avantage vient avec son inconvénient miroir : tu ne peux pas faire de l'analyse statique pour déterminer les dépendances (alors qu'avec un paquet apt, il suffit de lire un fichier de contrôle pour avoir toutes les dépendances).