Oui dans le cas d’une bibliothèque que l’on va partager, ici ça n’était pas le cas, mais je ne l’ai pas précisé. Il s’agissait d’une produit final où on veut maîtriser les versions utilisées.
Et pas tout à fait car à mon sens il vaudrait mieux utiliser <N+1 pour garantir que l’on va rester avec une dépendance compatible.
Exemple :
On utilise une version 1.X.Y d’une lib. Celle-ci passe en version 2.0.0 et le changelog indique que certaines API sont cassées. Que fait-on ?
[^] # Re: cache
Posté par Chmoldu . En réponse au journal Envoyer des Python à roues. Évalué à 1.
C’est précisément l’objectif ici, se créer un dépôt que l’on conserve pour refaire des installes/images docker plus rapidement.
Par contre pour que
pip installmette en cache les wheel il faut que le paquetwheelsoit installé si je ne m’abuse ?[^] # Re: Versionning absolue des dépendances considered harmful
Posté par Chmoldu . En réponse au journal Envoyer des Python à roues. Évalué à 3. Dernière modification le 05 mars 2018 à 11:44.
Oui… et pas tout à fait.
Oui dans le cas d’une bibliothèque que l’on va partager, ici ça n’était pas le cas, mais je ne l’ai pas précisé. Il s’agissait d’une produit final où on veut maîtriser les versions utilisées.
Et pas tout à fait car à mon sens il vaudrait mieux utiliser <N+1 pour garantir que l’on va rester avec une dépendance compatible.
Exemple :
On utilise une version 1.X.Y d’une lib. Celle-ci passe en version 2.0.0 et le changelog indique que certaines API sont cassées. Que fait-on ?
# Précision - compatibilité binaire
Posté par Chmoldu . En réponse au journal Envoyer des Python à roues. Évalué à 6.
Les noms des .whl expliqué par la PEP 427 : https://www.python.org/dev/peps/pep-0427/#file-name-convention