1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
introduce package and setup.py less sdist creation
-----------------------------------------------------------
Example sections for tox itself::
[pkgdef]
basename = pytest
description = virtualenv-based automation of test activities
authors = holger krekel <holger@merlinux.eu>
url = http://tox.testrun.org
entry_points = console_scripts: tox=tox:cmdline
requires = py
packages =
preuploadenvs = sphinx
classifiers=
Development Status :: 6 - Mature
Intended Audience :: Developers
License :: OSI Approved :: MIT License
Topic :: Software Development :: Testing
Topic :: Software Development :: Libraries
Topic :: Utilities
This would generate three different packages:
- the main one containing the app with the specified description, etc.
It has a test-requires pointing to the test package,
which classifiers
- the test package only containing the tests and setup.py
depending on the main package and all requirements collected from the
testenv
- the doc package containing generated html and txt files
(to be installable via a setup.py as well?)
Here is what happens when tox is invoked now:
- version gets auto-incremented (in setup.py and $PACKAGE/__init__.py files)
- main setup.py generated, files copied, sdist generated
- test setup.py generated, files copied, sdist generated
- doc setup.py generated, doc environment run, files copied, sdist generated
- if --upload is specified, all packages are uploaded under
their respective names:
tox-VER
tests-tox-VER
docs-tox-VER
- tox --sync creates a test result file for the tests-tox-VER run
and uploads it to testrun.org -- .tox/projectkeys contains a file that
was created by visiting testrun.org and registering/logging in.
- download toxslave and execute it:
toxslave --userkey=... [--project tox]
which will query testrun.org for outstanding testruns
[for the tox project], download packages, execute them
and report back to the server
merge tox and detox?
----------------------------------------------------------------
maybe it's time to merge it?
http://lists.idyll.org/pipermail/testing-in-python/2012-October/005205.html
pyc files / test distributions
-----------------------------------------------------------
investigate pyc cleaning, see
http://lists.idyll.org/pipermail/testing-in-python/2012-October/005205.html
allow config overlays
-----------------------------------------------------------
tags: 1.5 feature
You can specify wildcards in section titles.
[testenv]
testsrc=testing/**.py
commands=py.test {posargs}
[testenv:py3*]
use2to3 = True
[testenv:py32]
deps =
...
Configuration values are now looked up in a stricter-matches-first
manner: If environment "py32" is considered then first the
section under py32, then py3*, then testenv.
support 2to3 configurations / test file postprocessing
-----------------------------------------------------------
tags: 1.5 feature
Tests should be copied and transformed before being executed.
Setup a test definition::
[testenv]
testsrc=testing/**.py
commands=py.test {posargs}
[testenv:py3*]
use2to3 = True
would transform all specified test files for all py3 environments
such that a subsequent test run::
$ tox -e py25,py32 testing/test_hello.py
causes a transformation of the test files to prepare test runs on
Python3 interpreters. The ``posargs`` specified files will be rewritten
to point to the transformed test files.
export support for travis
----------------------------------------
tag: 1.6 feature
look into ways to support integration of tox with travis.
- run tox from travis
- let tox read commands from travis config
- generate .travis.yml from tox.ini
- generate tox.ini from .travis.yml
For the last two, take a look at http://pypi.python.org/pypi/panci/
allow user-specific python interpreters
------------------------------------------------
users should be able to define their set of python executables
to be used for creating virtualenvs.
.toxrc/interpreters:
pypy-c=~/p/pypy/branch/sys-prefix/pypy-c
...
non-cached test dependencies
---------------------------------------------------------------
if there is a dependency on a URL whose content changes
the download-cache mechanism will prevent it from being reloaded.
Introduce a 'nocache:' prefix which will inhibit using the cache.
Also make and document a guarantee on the deps order so that
one can influence the exact configuration (e.g. use a dev-version
of some package which a later dependency or the original
package depends upon - i.e. deps should be installed first).
test and make "in-pkg" tests work
---------------------------------------
it is common to put tests into pkg subdirs, possibly
even with an __init__. See if/how this can be made
to work. Maybe also re-consider how py.test does its
importing, maybe add a pytest_addsyspath(testmodule)
and look how nose does it in detail.
|
