tox

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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:

  1. 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. 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)

  2. 1 virtualenv seulement avec les dépendances de documentation

  3. processus d'installation simplifie

  4. 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.

+1 -0
Staff

Merci beaucoup pour ce poste pour qu'on puisse discuter un peu.

En tout cas, même si je n'arrive pas à voir ce que ça apporterait de plus avec ce qu'on a actuellement parce que je ne connais pas suffisamment l'écosystème python, c'est toujours sympa de découvrir qu'il existe une quantité massive d'outils pour aider les devs ^^

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte