poetry
poetry copied to clipboard
python-poetry
tests: use tmp_path fixture
Pull Request Check List
Resolves: #6934
- [ ] ~Added tests for changed code.~
- [ ] ~Updated documentation for changed code.~
There's an old PR https://github.com/python-poetry/poetry/pull/7129 but From last year and it was not updated.
As @radoering noted the current CI tests in windows has a similar fail with the other PR https://github.com/python-poetry/poetry/pull/7129.
I have added some code for debugging the failed Windows pipelines because the error output is truncated.
The problem appears to be the pytest.tmp_path path prefix making the file paths too long.
Cloning into 'C:/Users/runneradmin/AppData/Local/Temp/pytest-of-runneradmin/pytest-0/popen-gw0/test_system_git_called_when_co0/.cache/pypoetry/src/test-fixture-vcs-repository/submodules/sample-namespace-packages'...
fatal: cannot write keep file 'C:/Users/runneradmin/AppData/Local/Temp/pytest-of-runneradmin/pytest-0/popen-gw0/test_system_git_called_when_co0/.cache/pypoetry/src/test-fixture-vcs-repository/.git/modules/submodules/sample-namespace-packages/objects/pack/pack-c638ec21e7fcb21acf4e0b89cefcdb31ab0adc29.keep': Filename too long
https://github.com/python-poetry/poetry/actions/runs/4364500429/jobs/7631897284#step:14:2832
Just on a curious note. I am getting a failing test in the pipeline which errors out on code that doesn't exist at this point in time.
The error:
==================================== ERRORS ====================================
_______ ERROR at setup of test_execute_prints_warning_for_invalid_wheels _______
[gw1] linux -- Python 3.7.16 /home/runner/work/poetry/poetry/.venv/bin/python
file /home/runner/work/poetry/poetry/tests/installation/test_executor.py, line 341
def test_execute_prints_warning_for_invalid_wheels(
E fixture 'tmp_dir' not found
> available fixtures: artifact_cache, auth_config_source, cache, capfd, capfdbinary, caplog, capsys, capsysbinary, class_mocker, config, config_cache_dir, config_dir, config_source, config_virtualenvs_path, copy_wheel, cov, current_env, current_python, default_python, doctest_namespace, download_mock, dummy_keyring, env, environ, fixture_base, fixture_copier, fixture_dir, git_mock, http, installed, io, io_decorated, io_not_decorated, isolate_environ, load_required_fixtures, mock_file_downloads, mock_user_config_dir, mocked_open_files, mocker, module_mocker, monkeypatch, no_cover, package_mocker, pep517_metadata_mock, pool, project_factory, project_root, pytestconfig, record_property, record_testsuite_property, record_xml_attribute, recwarn, repo, required_fixtures, session_mocker, set_simple_log_formatter, testrun_uid, tmp_path, tmp_path_factory, tmp_venv, tmpdir, tmpdir_factory, wheel, with_chained_fail_keyring, with_chained_null_keyring, with_fail_keyring, with_null_keyring, with_simple_keyring, worker_id
> use 'pytest --fixtures [testpath]' for help on them.
/home/runner/work/poetry/poetry/tests/installation/test_executor.py:341
https://github.com/python-poetry/poetry/actions/runs/4583142389/jobs/8093814943?pr=7412#step:14:2715
The file at the current commit of the pipeline run: https://github.com/python-poetry/poetry/blob/39662eee491b537aebda22e504577176361db3be/tests/installation/test_executor.py#L341
I am getting a failing test in the pipeline which errors out on code that doesn't exist at this point in time.
looks like the pipeline is smart enough to checkout the merge commit that would happen, if this MR were to be merged. (That sounds like what you'd want, else the pipeline could pass but then fail on the master branch as soon as it was merged).
You're going to want to merge or rebase from master sooner or later anyway, suggest you do that.
looks like the pipeline is smart enough to checkout the merge commit that would happen, if this MR were to be merged.
I did not expect that. Thanks. I just rebased, a second time, but will do again.
Wow. Didn't know the CI list is a scrolly frame. Thought I just didn't have permission to see all the CIs. The black was fixed. Not sure how it got past as I do have pre-commit installed.
#7784 kicks in and tells us something about the flakey CI!
https://github.com/python-poetry/poetry/actions/runs/4669647501/jobs/8268387674?pr=7412
Traceback (most recent call last):
File "C:\Users\RUNNER~1\AppData\Local\Temp\tmpmn5fwvjz\.venv\lib\site-packages\build\__init__.py", line 466, in _handle_backend
yield
File "C:\Users\RUNNER~1\AppData\Local\Temp\tmpmn5fwvjz\.venv\lib\site-packages\build\__init__.py", line 356, in get_requires_for_build
return set(get_requires(config_settings))
File "C:\Users\RUNNER~1\AppData\Local\Temp\tmpmn5fwvjz\.venv\lib\site-packages\pyproject_hooks\_impl.py", line 166, in get_requires_for_build_wheel
return self._call_hook('get_requires_for_build_wheel', {
File "C:\Users\RUNNER~1\AppData\Local\Temp\tmpmn5fwvjz\.venv\lib\site-packages\pyproject_hooks\_impl.py", line 311, in _call_hook
self._subprocess_runner(
File "C:\Users\RUNNER~1\AppData\Local\Temp\tmpmn5fwvjz\.venv\lib\site-packages\build\__init__.py", line 302, in _runner
self._hook_runner(cmd, cwd, extra_environ)
File "C:\Users\RUNNER~1\AppData\Local\Temp\tmpmn5fwvjz\.venv\lib\site-packages\pyproject_hooks\_impl.py", line 71, in quiet_subprocess_runner
check_output(cmd, cwd=cwd, env=env, stderr=STDOUT)
File "C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\subprocess.py", line 424, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File "C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\subprocess.py", line 528, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['C:\\Users\\runneradmin\\AppData\\Local\\Temp\\build-env-k65ld4h9\\Scripts\\python.exe', 'C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\tmpmn5fwvjz\\.venv\\lib\\site-packages\\pyproject_hooks\\_in_process\\_in_process.py', 'get_requires_for_build_wheel', 'C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\tmp95wnwt0t']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 16, in <module>
File "C:\Users\RUNNER~1\AppData\Local\Temp\tmpmn5fwvjz\.venv\lib\site-packages\build\__init__.py", line 356, in get_requires_for_build
return set(get_requires(config_settings))
File "C:\hostedtoolcache\windows\Python\3.9.13\x64\lib\contextlib.py", line 137, in __exit__
self.gen.throw(typ, value, traceback)
File "C:\Users\RUNNER~1\AppData\Local\Temp\tmpmn5fwvjz\.venv\lib\site-packages\build\__init__.py", line 474, in _handle_backend
raise BuildBackendException( # noqa: B904 # use raise from
build.BuildBackendException: Backend subprocess exited when trying to invoke get_requires_for_build_wheel
Not sure what to make of that to be honest, but it's some sort of progress
Windows 3.9 is the one that's stuck on old virtualenv, possibly relevant
test_info_setup_missing_mandatory_should_trigger_pep517[name]
It's the test case with the missing name in setup.py.
error: Invalid distribution name or version syntax: poetry-config-5k08imt--0.1.0
Is it possible that the name of some temporary directory is used as package name and that if we are unlucky this name ends with a dash so that we get an invalid name? (Can't look for myself right now.)
#7784 kicks in and tells us something about the flakey CI!
I have rebased to pull it in.
I have rebased to pull it in.
As previously discussed - https://github.com/python-poetry/poetry/pull/7412#issuecomment-1493409146 - the pipeline was doing that already
flakey test is on windows 3.10 this time, and mentions poetry-config-fxu7gvb--0.1.0 - so that knocks out the virtualenv theory and is consistent with the "awkwardly named temporary directory" theory.
Given that this MR seems to be hitting this problem much more than any other branch, and the hint that it's to do with the name of a temporary directory... probably you need to get to the bottom of this one - or at least far enough to show that it's not related to this MR - before merging.
It seems that the failure is really caused by this PR:
After setting a breakpoint at https://github.com/python-poetry/poetry/blob/5a9da19fa85631f46a5f1edc9e61c2b65255dab2/tests/inspection/test_info.py#L236
I noticed that source_dir is empty without this PR, but contains two directories .cache and something like poetry_config_jz_t48_l with this PR.
If there is no name in setup.py and there is exactly one directory (directories starting with a dot don't count as it seems) next to setup.py, setuptools assumes that's the name. If there are two folders setuptools raises an exception. If there is no folder, setuptools sets the name to UNKNOWN.
Thus, the question is what change of this PR creates these two directories?
OK, it's clear now: config_cache_dir and config_dir in conftest.py used tmp_dir before and source_dir in test_info.py used tmp_path, so we had two different directories and now it's all the same.
I suppose we should change https://github.com/python-poetry/poetry/blob/5a9da19fa85631f46a5f1edc9e61c2b65255dab2/tests/inspection/test_info.py#L38-L39
- return Path(tmp_path.as_posix())
+ path = tmp_path / "source"
+ path.mkdir()
+ return path
OK, it's clear now:
config_cache_dirandconfig_dirinconftest.pyusedtmp_dirbefore andsource_dirintest_info.pyusedtmp_path, so we had two different directories and now it's all the same.I suppose we should change
https://github.com/python-poetry/poetry/blob/5a9da19fa85631f46a5f1edc9e61c2b65255dab2/tests/inspection/test_info.py#L38-L39
- return Path(tmp_path.as_posix()) + path = tmp_path / "source" + path.mkdir() + return path
Thanks a lot for the investigation. I don't think I would've been able to figure it out on my own, especially on Win. Is there a way to trigger CI re-run on GH, to make sure its not passing by chance since it was manifesting itself randomly?
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}