-
-
Notifications
You must be signed in to change notification settings - Fork 509
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
{env_name} substitution broken since version 4.14.1 #3292
Comments
I tried to re-create this but in my case, I'm able to use {env_name}. [testenv:temp]
commands =
python -c "print(r'{env_name}')"
|
Hi @shekhuverma, Indeed, that works for me as well. But as noted earlier:
I did some further investigation, and managed to create a minimal reproducible example: This example shows that the issue did not exist in tox 4.14.0, while it does in 4.14.1: MINGW64 ~/github/tox-issue-3292 (main)
$ py -3.11 -m tox run
.pkg: install_requires> python -I -m pip install setuptools>61 setuptools_scm[toml]>=7.0
.pkg: _optional_hooks> python C:\Python\311\Lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__
.pkg: get_requires_for_build_wheel> python C:\Python\311\Lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__
.pkg: install_requires_for_build_wheel> python -I -m pip install wheel
.pkg: build_wheel> python C:\Python\311\Lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__
py311: install_package> python -I -m pip install --force-reinstall --no-deps C:\Users\rhabarberbarbara\github\tox-issue-3292\.tox\.tmp\package\1\mypackage-0.1.dev2+g833b951-py3-none-any.whl
py311: commands[0]> python -m mypackage run --data-file=.coverage.{env_name} --branch
Running mypackage with: ['run', '--data-file=.coverage.{env_name}', '--branch']
py311: OK (23.69=setup[23.53]+cmd[0.16] seconds)
congratulations :) (24.03 seconds)
MINGW64 ~/github/tox-issue-3292 (main)
$ py -3.11 -m tox run -x 'tox.requires=tox<4.14.1'
ROOT: will run in automatically provisioned tox, host C:\Python\311\python.exe is missing [requires (has)]: tox<4.14.1 (4.15.1)
ROOT: install_deps> python -I -m pip install tox<4.14.1 tox>=4
ROOT: provision> .tox\.tox\Scripts\python.exe -m tox run -x tox.requires=tox<4.14.1
.pkg: _optional_hooks> python C:\Users\rhabarberbarbara\github\tox-issue-3292\.tox\.tox\Lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__
.pkg: get_requires_for_build_wheel> python C:\Users\rhabarberbarbara\github\tox-issue-3292\.tox\.tox\Lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__
.pkg: build_wheel> python C:\Users\rhabarberbarbara\github\tox-issue-3292\.tox\.tox\Lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__
py311: install_package> python -I -m pip install --force-reinstall --no-deps C:\Users\rhabarberbarbara\github\tox-issue-3292\.tox\.tmp\package\2\mypackage-0.1.dev2+g833b951-py3-none-any.whl
py311: commands[0]> python -m mypackage run --data-file=.coverage.py311 --branch
Running mypackage with: ['run', '--data-file=.coverage.py311', '--branch']
.pkg: _exit> python C:\Users\rhabarberbarbara\github\tox-issue-3292\.tox\.tox\Lib\site-packages\pyproject_api\_backend.py True setuptools.build_meta __legacy__
py311: OK (3.53=setup[3.39]+cmd[0.14] seconds)
congratulations :) (4.02 seconds) The issue somehow seems tied to the presence of the |
Bisected to #3237 Trying to fix the issue |
Oh, I was just about to post an issue about this. It was super weird to debug. removing some testsenvs made it work adding more (even empty) triggered it again. I still don't understand the underlying cause but I ended up boiling it down to a small reproducer: # tox.ini
[testenv:.pkg]
[testenv:bug-demo]
package = skip with this, tox crashes as follows: $ tox r -e bug-demo -vvvvv
ROOT: 108 D setup logging to NOTSET on pid 2907185 [tox/report.py:221]
ROOT: 156 E HandledError| .pkg cannot self-package [tox/run.py:23] Interestingly, dropping cc @gaborbernat P.S. The |
PR Welcome. Note, however, that this is probably a difficult problem. |
@gaborbernat yeah, I figured it's difficult having spent hours... Any hints? Could you confirm that using |
I don't know what that stands for, but it is not recognized by the tool, unless you somehow configure it via references to use it. |
@gaborbernat the migration guide says it's the base env for building packages, IIUC: https://tox.wiki/en/latest/upgrading.html#packaging-configuration-and-inheritance. |
Alright, forgot about that change. Then it should work. |
xref possible duplicate: #3238 |
Oh, I see. You are correct. This is a duplicate issue closing as such. |
@gaborbernat I was just about to ask you to also label this as Anyway, I think there might be some useful context spread across these two issues so I wanted to make sure that the details get migrated over to the other one. @rhabarberbarbara @shekhuverma could you post/move any relevant details present in your investigation over at #3238 (those that might be missing there)? This will help consolidate all the info gathered by different people in disconnected places... |
Issue
I'm creating a pipeline where a coverage report is generated over multiple test runs (spanning different Python versions). To do this, I want to include the tox environment in the coverage file name, so the artifacts don't overwrite each other in the pipeline job that combines the coverage files.
It's configured as follows (with some sections left out):
This worked fine up to tox 4.14.0:
However, from tox 14.4.1 onwards, the
env_name
variable isn't substituted anymore, and just comes through as{env_name}
Environment
Provide at least:
Output of
pip list
of the host Python, wheretox
is installedOutput of running tox
See above.
Minimal example
I tried to create a minimal example by creating a tox configuration that doesn't build and install a package, but for some reason the substitution in the command did work there. So somehow the package building and installing is important for the issue to occur.
Unfortunately, I can't share my entire tox config, as it's part of a corporate repo.
The text was updated successfully, but these errors were encountered: