Running tox in parallel specifying CPU counts produces wrong results

[UniversalExtensionsDev]

Hello, I am new to tox, and still trying to figure it out, so I would like some help to understand the following puzzling issue.

I am unning the following command, where build_dependencies reflects to 4 testenvs py{37,38,39,30}-build_deps:

tox run-parallel -m build_dependencies --parallel 2 --parallel-no-spinner

With every execution of testenv build_dependencies, my project is getting built and I'm expecting a .whl file to be generated (I wish to do it that way since there is a custom logic behind this build). So in total, I expect to see 4 .whl files.

I have noticed that when I'm running this testenv in parallel on a VM with 2vCPUS, only 2 .whl files are getting generated. However, when I run this on a VM with 4vCPUS all 4 wheels are generated. All 4 files are stored under the same directory, but I havent' came across any kind of IO error due to file descriptors accessing the same files/dirs.

So, I would expect the same number of wheel files to be generated in both VMs, but with an obvious delay on the one with the 2vCPUs.

[jugmac00]

FWIW I think

py{37,38,39,30}-build_deps

should be

py{37,38,39,310}-build_deps

Can you list the wheels?

In case you do not leverage e.g. C code, and you are using pure Python, the wheels should be the same for all Python versions, and generating one wheel per CPU is either an optimization or an oversight.

@gaborbernat Thoughts?

[IoannaT]

Thanks for the prompt reply (author of the raised question here :) )

You are right, I made a typo there. In fact, all my testenvs are:

$ tox -l
linting
py37-unit_test
py38-unit_test
py39-unit_test
py310-unit_test
coverage
py37-build_deps
py38-build_deps
py39-build_deps
py310-build_deps
build_all

The wheel files should be generated due to requirements with C bindings, but also to cover multiple Python versions.
An example of my expected wheel files, when running -m build_dependencies:

my_project-1.1.0-cp310-cp310-linux_x86_64.whl
my_project-1.1.0-cp37-cp37m-linux_x86_64.whl
my_project-1.1.0-cp38-cp38-linux_x86_64.whl
my_project-1.1.0-cp39-cp39-linux_x86_64.whl

Just making sure we're on the same page; these wheel files are not generated by tox (i.e packaging process), but based on the setup.py of my_project. The problem comes only when running tox in parallel...

[gaborbernat]

For this exact reason, tox usually employs a lock whenever working with packaging of environments. This might be a bug on our side cuz I don't think we lock when different environments build the same project. If the packaging directory is the same, I think we should employ universal lock for all of them.

[IoannaT]

So I went through the .tox/<testenv>logs>commands, and noticed that for the "missing" wheel files (i.e in the case of the 2vCPU VM), the building logs generated from my project's setup.py, contain an error message that points to concurrent accessing of the same files...
However, this error (wrongly) does not cause the build command to stop, leading to a successful tox testenv execution.
Thus, nothing wrong with tox I guess :)