en suite a la demande sur github voici ma proposition pour utiliser l'outil tox.
Cartouche | |
---|---|
ZEP | ? |
Titre | adoption de tox pour le setup du virtual environment pour tests et creation de documentation |
Révision | ? |
Date de création | 2014 Decembre 06 |
Dernière révision | - |
Type | Process |
Statut | Rédaction |
le contexte de la proposition :
Le process actuel de setup le virtualenv, dependances et test peuvent etre ammeliore avec tox.
C'est quoi tox?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Tox is a generic virtualenv management and test command line tool you can use for: - checking your package installs correctly with different Python versions and interpreters - running your tests in each of the environments, configuring your test tool of choice - acting as a frontend to Continuous Integration servers, greatly reducing boilerplate and merging CI and shell-based testing. - automation of tedious Python related test activities - test your Python package against many interpreter and dependency configs - automatic customizable (re)creation of virtualenv test environments - installs your setup.py based project into each virtual environment - test-tool agnostic: runs py.test, nose or unittests in a uniform manner - supports using different / multiple PyPI index servers - uses pip and setuptools by default. Experimental support for configuring the installer command through install_command=ARGV. - cross-Python compatible: CPython-2.6, 2.7, 3.2 and higher, Jython and pypy. - cross-platform: Windows and Unix style environments - integrates with continuous integration servers like Jenkins (formerly known as Hudson) and helps you to avoid - boilerplatish and platform-specific build-step hacks. - full interoperability with devpi: is integrated with and is used for testing in the devpi system, a versatile - pypi index server and release managing tool. - driven by a simple ini-style config file - documented examples and configuration - concise reporting about tool invocations and configuration errors - professionally supported |
l'objet de la proposition :
L'utilisation de tox pour tester le project a les benefices suivants:
- gestion plus simple du virtualenv ou multiples virtualenvs pour d'autres version/interpreters de python ou pour des combinaisons version/interpreter python-version de django:
- python2.7
- python3.4
- python2.7 + django1.6.8
- python2.7 + django1.7.1
-
1..N virtualenv .tox/<pyXX> seulement avec les dependances du project et test necessaires pour cela l'interpreter et version de python choisi + version django (pas de dependances pour les docs)
-
1 virtualenv seulement avec les dépendances de documentation
-
processus d'installation simplifie
-
test du code Python simplifie
Pour installer, faire
1 | $ sudo port install py27-tox |
et on peut commencer a dev/test tout suite. tox prends en charge la creation du virtualenv, installation dependances, etc. Donc pour tester on a besoin de faire:
1 | $ tox |
simple.
Pour les docs, ce la meme chose:
1 | $ tox -e docs -- html |
les moyens mis en oeuvre:
- contribution deja faite ici
c'est pas sorcier.