Merci pour les différentes méthodes, je vais juste inclure les fichiers vu que ça va rester en interne. J’ai plus qu’à m’y mettre…

https://github.com/jaraco/path.py/issues/24

Pour l’intégration, ça dépend de ce que tu veux faire.

Si tu veux l’intégrer dans un projet web perso, il faut le mettre dans requirements.txt:

http://sametmax.com/votre-python-aime-les-pip/

Si tu le joints à une lib sur pypi, alors il faut le mettre dans le setup.py:

http://sametmax.com/creer-un-setup-py-et-mettre-sa-bibliotheque-python-en-ligne-sur-pypi/

Si c’est pour un projet tout con ou un deb (car je pense que path.py n’est pas dans les dépots), alors on peut juste filer le fichier dans l’archive.

Pour zerobin on fait un mix (pour d’autres libs que path.py), donc tu peux regarder comment en fait :

https://github.com/sametmax/0bin/tree/master/zerobin

On a la dépendance dans setup.py, qui est installé automatiquement. Mais si l’utilisateur télécharge l’archive des sources, il peut dezipper le projet et l’utiliser cash, sans rien installer, car on fournit les depannces avec pour ce format. Ce n’est pas toujours possible, mais là c’était facile à faire.

Une petite question : tu dis que l’auteur n’utilise pas @property pour garder la compatibilité python 2.5, mais il l’utilise pour la méthode uncshare()

Enfin, pour terminer, quelle serait la meilleure manière d’intégrer cette lib à un projet ? On place direct le fichier quelque part dans l’arborescence du projet ? On peut l’importer de manière automatique depuis le setup.py ? On demande à l’utilisateur de l’installer (dans le cas où le projet n’est pas grand public mais les utilisateurs sont sensé savoir se débrouiller un minimum) ? Je pense notamment aux mises à jour ou au fait qu’il est peut-être plus judicieux d’utiliser la lib du système si elle est présente.

Pour functools.lru_cache, je pense que c’est le fantome d’un comment qui n’a jamais été implémenté.

Du coup :

https://github.com/jaraco/path.py/issues/21

Parmi les choses sur lesquelles j’ai buté, la méthode using_module. Ton commentaire a l’air inexact.

Tu écris qu’elle retourne le module actuellement utilisé, ce qui me paraissait bizarre (suffit de faire path.module pour ça, et ça ne correspond pas au code: la méthode prend un module en paramètre et retourne une classe.

Je me suis retrouvé sur la repo de path et la discussion concernant la manière de permettre de “spécifier explicitement le module path a utiliser” (en l’occurence posix ou nt), ce qui a clarifié les choses.

Par ailleurs, les auteurs écrivent dans la méthode simple_cache:

When Python 3.2 is available, use functools.lru_cache instead.

.
Je ne comprend pas ce que ça signifie: a part cette mention, on ne voit functools.lru_cache nulle part dans le code.