j'ai tenté de modifier une lib pour mettre les sources dans un répertoire src/ à part.
L'avantage (cf. les pages pré-cités) c'est que ça permet que tox teste l'installation plutôt que les fichiers locaux, donc vérifie au passage que le setup.py merde pas. Ce qui est pas mal. J'ai déjà eu un cas où les tests passaient mais la lib marchait pas parce que certains fichiers étaient présents localement mais manquants dans le package.
J'ai essayé de faire ça, donc, et ça soulevait d'autres questions.
Aujourd'hui, quand je teste avec pytest + coverage sur 3 version de python, la couverture qui est remontée est l'union des trois tests. C'est bien parce qu'en général c'est la même chose pour les trois versions, juste quelques wrappers de compatibilité qui changent. Mais dans l'absolu, ça "prouve" pas qu'on a une bonne couverture sur une version en particulier. Sur cet exemple, c'est pas dramatique, mais plutôt que des versions de Python, ça peut être des libs ou des versions de lib.
Quand on déplace le code source dans /src, tox différencie les environnements et renvoie une couverture pour chaque version (environnement tox) de chaque fichier. Les blogs cités plus haut indiquent une méthode pour fusionner les couvertures et avoir l'union des couvertures, mais ça commence à faire lourd en bidouilles pour pas grand-chose.
Pour finir, j'ai conservé la structure actuelle qui est celle des bibliothèques que je connais et celle que vous présentez.
Avez-vous un commentaire sur la limitation de cette structure via-à-vis de pytest / tox ?
[^] # Re: Slides du talk sur le packaging
Posté par jihele . En réponse au journal PyConfr2017 - Boudu !. Évalué à 2.
Merci pour les diapos. J'étais pas à la PyCon.
Récemment, à la lecture de ces pages :
https://blog.ionelmc.ro/2014/05/25/python-packaging/
https://hynek.me/articles/testing-packaging/
j'ai tenté de modifier une lib pour mettre les sources dans un répertoire src/ à part.
L'avantage (cf. les pages pré-cités) c'est que ça permet que tox teste l'installation plutôt que les fichiers locaux, donc vérifie au passage que le setup.py merde pas. Ce qui est pas mal. J'ai déjà eu un cas où les tests passaient mais la lib marchait pas parce que certains fichiers étaient présents localement mais manquants dans le package.
Cf aussi la doc de pytest : https://docs.pytest.org/en/latest/goodpractices.html#tests-outside-application-code
J'ai essayé de faire ça, donc, et ça soulevait d'autres questions.
Aujourd'hui, quand je teste avec pytest + coverage sur 3 version de python, la couverture qui est remontée est l'union des trois tests. C'est bien parce qu'en général c'est la même chose pour les trois versions, juste quelques wrappers de compatibilité qui changent. Mais dans l'absolu, ça "prouve" pas qu'on a une bonne couverture sur une version en particulier. Sur cet exemple, c'est pas dramatique, mais plutôt que des versions de Python, ça peut être des libs ou des versions de lib.
Quand on déplace le code source dans /src, tox différencie les environnements et renvoie une couverture pour chaque version (environnement tox) de chaque fichier. Les blogs cités plus haut indiquent une méthode pour fusionner les couvertures et avoir l'union des couvertures, mais ça commence à faire lourd en bidouilles pour pas grand-chose.
Pour finir, j'ai conservé la structure actuelle qui est celle des bibliothèques que je connais et celle que vous présentez.
Avez-vous un commentaire sur la limitation de cette structure via-à-vis de pytest / tox ?