-
-
Notifications
You must be signed in to change notification settings - Fork 523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for phony environments #427
Comments
Phony environments could be specified as follows:
On another note, for environments that do not really test anything (build docs, build installer), it is strange that the environment needs to be specified as |
Using tox as a pythonic make replacement seems to become more and more common and it surely is a good idea to think about how needs growing from that can better be accommodated. Regarding your About your other point (having sections being named more fittingly for the tasks): I see your point, but I don't have an opinion about this yet. |
it would be useful to use this as a circuit breaker too, so the phony stops on the first failure of one of the environments. though it should be configurable whether a fail aborts or not, as one of my current would-e-a-use-case shows: [phony:all]
envlist = flake8, mypy, unittests, integration
abortonfail = True
[phony:integration]
envlist = integrationrun, teardown-redis-container
abortonfail = False ; ensure the container is stopped
[phony:integrationrun]
envlist = setup-redis-container, integrationtests
abortonfail = True hm, this is rather complicated. i'd prefer something like boolean operators and expressions grouped by parenthesis. |
I like to define "shortcuts" as well in my tox conf, like: [testenv:check]
skip_install = true
commands = tox -e checksetup,checksafety,checkstyle,checkspell,checklink
[testenv:checksetup]
... Also, I can't do: [tox]
envlist = check,docs,test
[testenv:test]
commands = tox -e py27-django19,py34-django19 ... because |
Duplicate of #647. |
…nments Having tox call tox is a bit weird, but the alternatives are: - duplication of the test command, which is a bit sad - replacing all the positive factors with conjunction of negative factors, e.g. `core` -> `!db-!server`, which makes the logic painful to follow One day, tox will have environment aliases which will make this horror moot :-) (Idea pulled from a comment in tox-dev/tox#427)
Tox can also be used as a make tool. For example, I created targets/environments to build the documentation for my project (Sphinx), an stand-alone installer for Windows and a stand-alone Mac application.
The
envlist
value in[tox]
intox.ini
allows specifying which environments should be executed when not specifying one manually. I only include the test environments inenvlist
. It would be nice if it were possible to define fake environments that simply execute a number of other (real) environments. This would also be useful for pure test environments.The text was updated successfully, but these errors were encountered: