Skip to content
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

Closed
brechtm opened this issue Dec 19, 2016 · 5 comments
Closed

Support for phony environments #427

brechtm opened this issue Dec 19, 2016 · 5 comments
Labels
area:configuration level:hard rought estimate that this might be quite hard to implement needs:discussion It's not quite clear if and how this should be done

Comments

@brechtm
Copy link

brechtm commented Dec 19, 2016

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] in tox.ini allows specifying which environments should be executed when not specifying one manually. I only include the test environments in envlist. 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.

@brechtm
Copy link
Author

brechtm commented Dec 19, 2016

Phony environments could be specified as follows:

[phony:docs]
envlist = test-docs, build-docs

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 [testenv:build-something]. Could another category of environments be introduced? For example [target:build-something] or [buildenv:build-something]. These environments could behave differently from test environments, but I'm not sure what would make sense. The default values could for skip_install and usedevelop could be set to true and false, respectively.

@obestwalter
Copy link
Member

obestwalter commented Dec 20, 2016

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 .Phony suggestion: this sounds like you are basically looking for #238 where the idea is also to group environments.

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.

@funkyfuture
Copy link

funkyfuture commented Mar 24, 2017

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.

@pawamoy
Copy link

pawamoy commented Mar 25, 2017

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 py27-django19 and py34-django19 are not defined in tox's envlist.

@obestwalter obestwalter added area:configuration needs:discussion It's not quite clear if and how this should be done level:hard rought estimate that this might be quite hard to implement and removed enhancement labels Sep 4, 2017
@gaborbernat
Copy link
Member

Duplicate of #647.

swhmirror pushed a commit to SoftwareHeritage/swh-core that referenced this issue Nov 21, 2019
…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-dev tox-dev locked and limited conversation to collaborators Jan 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area:configuration level:hard rought estimate that this might be quite hard to implement needs:discussion It's not quite clear if and how this should be done
Projects
None yet
Development

No branches or pull requests

5 participants