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

Specifying a single testenv with platform-dependent commands #2092

Open
felix-hilden opened this issue Jun 18, 2021 · 4 comments
Open

Specifying a single testenv with platform-dependent commands #2092

felix-hilden opened this issue Jun 18, 2021 · 4 comments
Labels
feature:new something does not exist yet, but should help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted.

Comments

@felix-hilden
Copy link

Hi again! I'd like to propose a feature to tox.

It would be convenient to have a single testenv with platform-dependent commands. This can be done to some extent with tox already:

[testenv]
platform = win32
commands = python -c 'import sys; print(sys.platform)'

Then we can have an environment for each platform. This would be ok for running tox without any arguments, but for running tasks manually, i.e. tox -e task, this is way worse because the user needs to remember the command for their specific platform, for example tox -e task-win. In this Stack Overflow question I attempted to make a single environment that could run platform-dependent commands, but was not successful. I'll summarise it here to provide syntax that I would have expected to work. Either one should be able to define the platforms independently in all test environments:

[tox]
envlist = task

[testenv:task]
platform =
    linux: linux
    mac: darwin
    win: win32
commands =
    linux: python -c 'print("Linux")'
    mac: python -c 'print("Mac")'
    win: python -c 'print("Win")'

Or defining the platforms in the top level testenv would be fine as well:

[tox]
envlist = task

[testenv]
platform =
    linux: linux
    mac: darwin
    win: win32

[testenv:task]
commands =
    linux: python -c 'print("Linux")'
    mac: python -c 'print("Mac")'
    win: python -c 'print("Win")'

Please don't hesitate to close this issue if it's already a thing in tox 4, or if I'm simply doing something wrong. Also, I'd be fine with this being introduced in tox 4 instead of the 3.x series, because it's already on the way.

@felix-hilden felix-hilden added the feature:new something does not exist yet, but should label Jun 18, 2021
@jugmac00
Copy link
Member

Hi @felix-hilden - you could do us a favor and test this on tox4 yourself.

Just pip install --pre tox and then use the tox4 binary instead of the tox binary.

If you rely on tox, it is a good idea anyway to test the pre-release in order to make sure your app/library will continue to work with tox after the final release.

@felix-hilden
Copy link
Author

Thanks for the tip! I'm not sure which syntax would be the right one, but I'll give it a go later today!

@felix-hilden
Copy link
Author

felix-hilden commented Jun 18, 2021

@jugmac00 There is no behavioral difference between tox 3 and 4 neither in the cases presented in the SO question nor my suggestions here. The only visual difference is that I can't see the environment skips that would happen on Linux and Mac, but that could be just obscured behind all the command line noise I see (which is likely meant to be color: ←[1m←[35mplatform-win:←[0m←[36m install_package> python -I -m pip install...)

@jugmac00
Copy link
Member

Thank you!

If you experience problems with color rendering, please create a new issue with some minimal steps to reproduce the problem.

Other than that - the todo list for tox is long - if you feel like, do not hesitate to implement this feature on your own (for tox 4 then) - pull request welcome. But please wait until @gaborbernat has read this and says that he would accept a PR, too.

@gaborbernat gaborbernat added this to the 4.0 milestone Jan 13, 2022
@gaborbernat gaborbernat modified the milestones: 4.0, 4.1 Nov 20, 2022
@gaborbernat gaborbernat added the help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted. label Jun 16, 2023
@gaborbernat gaborbernat removed this from the P-1 milestone Jun 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature:new something does not exist yet, but should help:wanted Issues that have been acknowledged, a solution determined and a PR might likely be accepted.
Projects
None yet
Development

No branches or pull requests

3 participants