tox 4 no longer creates session views for packages

[bmorris3]

Issue

CI with tox often begins by upgrading tox (with python -m pip install --upgrade pip tox), but in the last hour since the latest tox release, running tox with the latest version is causing an error. See a build log here which fails, even though previous builds succeeded (like this one). Excerpt below:

Run tox -e py310-test-alldeps-cov -- --remote-data
.pkg: install_requires> python -I -m pip install setuptools setuptools_scm wheel
.pkg: _optional_hooks> python /opt/hostedtoolcache/Python/3.10.8/x64/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta
.pkg: get_requires_for_build_sdist> python /opt/hostedtoolcache/Python/3.10.8/x64/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta
.pkg: install_requires_for_build_sdist> python -I -m pip install setuptools_scm
.pkg: prepare_metadata_for_build_wheel> python /opt/hostedtoolcache/Python/3.10.8/x64/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta
.pkg: build_sdist> python /opt/hostedtoolcache/Python/3.10.8/x64/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta
py310-test-alldeps-cov: install_package_deps> python -I -m pip install 'asdf>=2.7.4' 'asteval>=0.9.23' 'astropy>=4.3' astroquery 'bqplot-image-gl>=1.4.[11](https://github.com/spacetelescope/jdaviz/actions/runs/3641786210/jobs/6148140940#step:5:12)' 'bqplot>=0.[12](https://github.com/spacetelescope/jdaviz/actions/runs/3641786210/jobs/6148140940#step:5:13).36' 'echo>=0.5.0' 'glue-astronomy>=0.5.1' 'glue-core>=1.6.0' 'glue-jupyter>=0.[14](https://github.com/spacetelescope/jdaviz/actions/runs/3641786210/jobs/6148140940#step:5:15).2' 'gwcs>=0.[16](https://github.com/spacetelescope/jdaviz/actions/runs/3641786210/jobs/6148140940#step:5:17).1' idna 'ipygoldenlayout>=0.3.0' 'ipypopout>=0.0.11' 'ipysplitpanes>=0.1.0' 'ipyvue>=1.6' 'ipyvuetify>=1.7.0' 'ipywidgets<8.0' matplotlib packaging 'photutils>=1.4' pytest pytest-astropy pytest-tornasync 'pyyaml>=5.4.1' 'regions>=0.6' scikit-image 'sidecar>=0.5.1' 'specreduce<1.3.0,>=1.2.0' 'specutils>=1.9' 'traitlets>=5.0.5' 'vispy>=0.6.5' 'voila<0.4,>=0.3.5'
py310-test-alldeps-cov: install_package> python -I -m pip install --force-reinstall --no-deps /home/runner/work/jdaviz/jdaviz/.tox/.pkg/dist/jdaviz-3.2.dev[18](https://github.com/spacetelescope/jdaviz/actions/runs/3641786210/jobs/6148140940#step:5:19)1+gcd9da78c.tar.gz
py310-test-alldeps-cov: commands[0] .tmp/py310-test-alldeps-cov> jupyter --paths
py310-test-alldeps-cov: exit 2 (0.00 seconds) .tmp/py310-test-alldeps-cov> jupyter --paths
.pkg: _exit> python /opt/hostedtoolcache/Python/3.10.8/x64/lib/python3.10/site-packages/pyproject_api/_backend.py True setuptools.build_meta
  py310-test-alldeps-cov: FAIL code 2 (85.30=setup[85.30]+cmd[0.00] seconds)
  evaluation failed :( (85.85 seconds)

Environment

Provide at least:

• OS: ubuntu-latest (github actions)

[jugmac00]

Hey @bmorris3

To get your CI unblocked, please pin tox < 4 until we figure out what goes wrong.

Next, please provide the requested information from our bug issue template, that is the output of tox -rvv.

Fun fact... The first public alpha of tox was released almost two years ago.
https://pypi.org/project/tox/4.0.0a2/

It is usually a great idea to test new releases in advance. This both prevents broken CIs and makes the life of open source maintainers easier.

Thank you!

[pllim]

Hello! We're trying to figure it out over at astropy/astropy#14139 . @maxnoe thinks it might be the .tmp vs .temp renaming. In our case, we use https://github.com/OpenAstronomy/github-actions-workflows/ that always installs stable tox upstream for us, so we cannot control that. While I can suggest that they test against dev tox, it illustrates a case where downstream doesn't always have control of which version of tox that gets installed.

[pllim]

Update: Not the .tmp vs .temp.

[maxnoe]

Running:

❯ tox -e tests
.pkg: install_requires> python -I -m pip install cython==0.29.30 extension-helpers oldest-supported-numpy setuptools 'setuptools_scm>=6.2' wheel
.pkg: _optional_hooks> python /home/maxnoe/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta
.pkg: get_requires_for_build_sdist> python /home/maxnoe/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta
.pkg: prepare_metadata_for_build_wheel> python /home/maxnoe/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta
.pkg: build_sdist> python /home/maxnoe/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta
tests: install_package_deps> python -I -m pip install 'PyYAML>=3.13' 'numpy>=1.20' 'packaging>=19.0' 'pyerfa>=2.0'
tests: install_package> python -I -m pip install --force-reinstall --no-deps /home/maxnoe/Projects/astropy/.tox/.pkg/dist/astropy-5.3.dev82+g6f2ab0ed9.tar.gz
tests: commands[0] .temp/tests> pip freeze
tests: exit 2 (0.00 seconds) .temp/tests> pip freeze
.pkg: _exit> python /home/maxnoe/.local/anaconda/envs/astropy-dev/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta
  tests: FAIL code 2 (86.71=setup[86.71]+cmd[0.00] seconds)
  evaluation failed :( (87.10 seconds)

[maxnoe]

Is there a migration guide available for going 3 → 4?

[gaborbernat]

Is there a migration guide available for going 3 → 4?

https://tox.wiki/en/latest/faq.html#breaking-changes-in-tox-4 though if it's a bug there's no migration neeeded.

[gaborbernat]

Update: Not the .tmp vs .temp.

We can revert this change 👍 A PR to make this change would be welcome!

[maxnoe]

You misunderstood I think. The issue was not caused by the .tmp vs. .temp change....

[gaborbernat]

@maxnoe thinks it might be the .tmp vs .temp renaming.

From this, I deduced this is at least one of the issues.

[pllim]

@Cadair , how do we use a PR branch from tox as the installed tox if we also use OpenAstronomy template?

[dhomeier]

I tested #2614; it still fails on

python /opt/lib/python3.9/site-packages/pyproject_api/_backend.py True setuptools.build_meta

as above.

[maxnoe]

I found the issue I think: change_dir says that the directory is created if it doesn't exist, but that does not seem to be the case:

Change to this working directory when executing the test command. If the directory does not exist yet, it will be created (required for Windows to be able to execute any command).

with change_dir = foo the tests don't run and show the error above.

When I do mkdir foo myself before, it works.

[pllim]

So does this mean it is a bug, or we starting have to make our own dir from now on?

[gaborbernat]

Definitely a bug 👍

[bmorris3]

Thanks for the quick response!