Fix tox failing to find 'install.requires' under some circumstances

[okurz]

Same as in 94b8445 we should give the absolute path to install.requires to ensure it can be found.

I thought I could fix the setup.py but this didn't work. I will create a draft nevertheless so that we can discuss.

[AdamWill]

to make CI happy, can you add encoding="utf-8" and a comment to disable R1732 because we don't want to use with there? Thanks.

[AdamWill]

also, just out of interest, what are the "circumstances" here? I've never had a problem with this...

[perlpunk]

I have the same problem, so I will paste what I get. I have python 3.6 installed on openSUSE Leap 15.4.
I'll only show the output for the 3.10 venv:

% python3 --version
Python 3.6.15
% tox --version
2.9.1 imported from /usr/lib/python3.6/site-packages/tox/__init__.py
% tox
...
py310 inst-nodeps: /home/tina/develop/github/openQA-python-client/.tox/dist/openqa_client-4.2.0.zip
ERROR: invocation failed (exit code 1), logfile: /home/tina/develop/github/openQA-python-client/.tox/py310/log/py310-10.log
ERROR: actionid: py310
msg: installpkg
cmdargs: ['/home/tina/develop/github/openQA-python-client/.tox/py310/bin/pip', 'install', '-U', '--no-deps', '/home/tina/develop/github/openQA-python-client/.tox/dist/openqa_client-4.2.0.zip'
]

Processing ./.tox/dist/openqa_client-4.2.0.zip
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'error'
  ERROR: Command errored out with exit status 1:
  command: /home/tina/develop/github/openQA-python-client/.tox/py310/bin/python3 /home/tina/develop/github/openQA-python-client/.tox/py310/lib/python3.6/site-packages/pip/_vendor/pep517/in_p
rocess/_in_process.py get_requires_for_build_wheel /tmp/tmp9pmy12ys
       cwd: /tmp/pip-req-build-qqfsgfot
       Complete output (16 lines):
       Traceback (most recent call last):
    File "/home/tina/develop/github/openQA-python-client/.tox/py310/lib/python3.6/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 363, in <module>
      main()
      File "/home/tina/develop/github/openQA-python-client/.tox/py310/lib/python3.6/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 345, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/home/tina/develop/github/openQA-python-client/.tox/py310/lib/python3.6/site-packages/pip/_vendor/pep517/in_process/_in_process.py", line 130, in get_requires_for_build_wheel
    return hook(config_settings)
    File "/tmp/pip-build-env-ayqxa9d1/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 163, in get_requires_for_build_wheel
    config_settings, requirements=['wheel'])
    File "/tmp/pip-build-env-ayqxa9d1/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 143, in _get_build_requires
    self.run_setup()
    File "/tmp/pip-build-env-ayqxa9d1/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 158, in run_setup
    exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 39, in <module>
    install_requires=open(path.join(HERE, 'install.requires'), encoding='utf-8').read().splitlines(),
  FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pip-req-build-qqfsgfot/install.requires'
  ----------------------------------------
WARNING: Discarding file:///home/tina/develop/github/openQA-python-client/.tox/dist/openqa_client-4.2.0.zip. Command errored out with exit status 1: /home/tina/develop/github/openQA-python-cl
ient/.tox/py310/bin/python3 /home/tina/develop/github/openQA-python-client/.tox/py310/lib/python3.6/site-packages/pip/_vendor/pep517/in_process/_in_process.py get_requires_for_build_wheel /tm
p/tmp9pmy12ys Check the logs for full command output.
ERROR: Command errored out with exit status 1: /home/tina/develop/github/openQA-python-client/.tox/py310/bin/python3 /home/tina/develop/github/openQA-python-client/.tox/py310/lib/python3.6/si
te-packages/pip/_vendor/pep517/in_process/_in_process.py get_requires_for_build_wheel /tmp/tmp9pmy12ys Check the logs for full command output.

py310 installed: attrs==22.1.0,certifi==2022.9.24,charset-normalizer==2.0.12,coverage==6.2,freezegun==1.2.2,idna==3.4,importlib-metadata==4.8.3,iniconfig==1.1.1,mypy==0.971,mypy-extensions==0
.4.3,packaging==21.3,pluggy==1.0.0,py==1.11.0,pyparsing==3.0.9,pytest==7.0.1,python-dateutil==2.8.2,PyYAML==6.0,requests==2.27.1,six==1.16.0,tomli==1.2.3,typed-ast==1.5.4,types-PyYAML==6.0.12
,types-requests==2.28.11.2,types-urllib3==1.26.25.1,typing_extensions==4.1.1,urllib3==1.26.12,zipp==3.6.0

[okurz]

@perlpunk does the PR fix your case? Because for me it does not, referencing some tmpdir path

[perlpunk]

No, with this PR I get this instead:

FileNotFoundError: [Errno 2] No such file or directory: '/tmp/pip-req-build-qqfsgfot/install.requires'

[AdamWill]

Hm, fun. It does look like you're on pretty old tox there - 2.9.1 is from 2017. I guess pip is equally old? Maybe this is an old pip issue?

[AdamWill]

https://stackoverflow.com/questions/50737765/what-is-pip-req-build-temp-folder-used-for-can-i-prevent-using-it seems to be people discussing a similar problem in 2018, sadly no solution...

[AdamWill]

https://lightrun.com/answers/pypa-setuptools-pip-213-in-tree-builds-with-setuptools-do-not-clean-local-build-directories suggests this was changed in pip 21.3. seems like pip used to copy stuff out to a temporary folder and run there. I wonder how it decides what to copy? maybe that's the issue. A slightly 'odd' thing my projects do is use setuptools_scm rather than having a manifest, maybe that screwed up old pip?

[perlpunk]

pip 21.3.1 from /home/tina/.local/lib/python3.6/site-packages/pip (python 3.6)

[AdamWill]

but is that the pip actually in use at this point? it seems to be /home/tina/develop/github/openQA-python-client/.tox/py310/bin/pip...

[perlpunk]

ah yes:
pip 21.3.1 from /home/tina/develop/github/openQA-python-client/.tox/py310/lib/python3.6/site-packages/pip (python 3.6)
I find the 3.6 in there a bit weird.

[AdamWill]

yeah me too, I don't know what's going on there. seems like it's using stuff from the host system at that point, maybe?

[AdamWill]

Hum. So 21.3.1 was still capable of doing in-tree builds and out-of-tree builds, but it seems like in-tree was definitely the default at that point. I wonder if SUSE patched it or something?

[AdamWill]

also, is it possible to figure out what is in the temp directory pip's creating? does it leave it around after the failure, or can you interrupt?

[AdamWill]

well, I installed a Leap 15.4 VM and I can reproduce this, so I'll poke about at it a bit. One thing I can see: the reason we're getting things like .tox/py310/lib/python3.6 is that, for some reason, tox on a clean Leap 15.4 with only Python 3.6 thinks Python 3.6 is also 3.8, 3.9, 3.10 and 3.11. It should realize those versions are missing (like it does realize 3.7 is missing) and skip those environments, but instead it's creating them but they're all really Python 3.6:

test@opensuse154:~/openQA-python-client> for ver in 38 39 310 311; do .tox/py$ver/bin/python3 --version; done
Python 3.6.15
Python 3.6.15
Python 3.6.15
Python 3.6.15
test@opensuse154:~/openQA-python-client> 

so, that's one thing (and probably a bug to file against tox in Leap 15.4). but it does fail in the py36 environment which really is Python 3.6, so we can probably ignore this for our purposes and just use the py36 env and try to figure out why it's failing there.

[okurz]

Woah, that's really weird behaviour. @perlpunk care to report to the openSUSE package maintainer?

[perlpunk]

which package would that be?
https://software.opensuse.org/search?baseproject=ALL&q=tox
They all have different maintainers.

[okurz]

https://build.opensuse.org/package/show/devel:languages:python/python-tox

[AdamWill]

So, back to poking into this. One interesting(?) thing: on Fedora, a tox py36 environment gets pip 18.1; on Leap 15.4, a tox py36 environment gets pip 21.3.1. Leap's tox version is much older - 2.9.1 vs. 3.26.0 on the Fedora env I'm using to compare with (Fedora 37).

Installing pip is tox's job, and it seems to decide what version to install itself. I'm wondering if later versions of tox decided that it's not safe to install a newer version of pip in the tox 3.6 environment and pinned to the older 18.1, or something like that?

Aha. No, it's not quite that, but close, I think: tox-dev/tox#448 . As the Changelog puts it, "Virtual environments created now no longer upgrade pip/wheel/setuptools to the latest version. Instead the start packages after virtualenv creation now is whatever virtualenv has bundled in. This allows faster virtualenv creation and builds that are easier to reproduce."

That change is from 3.10.0. So, tox versions before that always updated pip, wheels and setuptools from the versions bundled by virtualenv; tox versions from 3.10.0 onwards do not do that. It seems like this results in py36 environments built with recent tox having an older pip, at least on Fedora. Assuming pip comes in via virtualenv somehow, I'm not 100% sure what virtualenv is being used, but that seems to be the upshot. All my tox envs have a pip-(version).virtualenv file, and you can see the versions...

./py36/lib/python3.6/site-packages/pip-18.1.virtualenv
./py37/lib/python3.7/site-packages/pip-22.2.2.virtualenv
./py38/lib/python3.8/site-packages/pip-22.2.virtualenv
./py39/lib/python3.9/site-packages/pip-22.2.2.virtualenv
./py310/lib/python3.10/site-packages/pip-22.2.virtualenv
./py311/lib/python3.11/site-packages/pip-22.2.virtualenv

so py37 and later get pip 22.2.2, but py36 gets 18.1. Still a lot of questions here, but this at least is an explanation why things differ for the py36 environment between Fedora 37 and Leap 15.4...

[AdamWill]

Ugh, so, I learned a lot, but I think this is actually much simpler. Please just try doing:
sudo zypper install python3-setuptools_scm
then try tox again. I bet it'll work now.

Leap 15.4's tox is so old it doesn't know about isolated_build = true, which we set in tox.ini, which tells it to do the sdist build in an isolated environment and install the build dependencies specified in pyproject.toml (and otherwise generally implements PEP-517). It does the sdist build in the host environment, using whatever bits are to hand; one of the major problems PEP-517 addressed was that, previously, there was no good way to define dependencies for building the sdist.

openQA-python-client , like my other projects, needs setuptools_scm installed in the environment that's building an sdist for it to be built correctly. If it isn't installed, lots of things get left out of the sdist, like the *.requires files. That's the problem we're running into here.

I don't know if there was an ugly old way to define build dependencies before PEP-517, maybe you can do something nasty in setup.py. If anyone knows, let me know. I'll see if I can find any old docs. Otherwise, you're just gonna have to know this is required :| I can at least mention it in the docs, I guess.

[AdamWill]

oh, the old way was setup_requires, I think. But IIRC if I add that back, I have to add a stupid workaround to the package spec file to say we don't need setuptools_scm there because we're not rebuilding the tarball. meh.

[perlpunk]

Thanks @AdamWill , I'll try it later today!

[perlpunk]

Indeed, it works. Thanks!

[okurz]

@perlpunk do you have a suggestion how I should change the PR then?

[AdamWill]

I doubt the PR is needed or useful.

As I said, we could add setup_requires = ["setuptools_scm"], but I don't really love it and I'm not 100% sure exactly what the result would be; weirdly, once I fixed this one time by installing setuptools_scm manually, I couldn't make it fail again even by removing it and wiping the .tox directory, so I couldn't test for sure if that did anything useful. I might do a fresh install and try it and see what happens if I get a minute.

This should only be a problem on fairly old platforms with tox earlier than 3.3.0 (which came out in 2018), and I kinda consider that a bit of a "doctor, it hurts". I might add a note to the README to say "develop on something modern or deal with the problems yourself". The changes to how Python development works since 2017 have made things way better, and I don't really want to commit to making things work with Ye Olde Ways; if anything I'm impatient to drop setup.py entirely, which would set a much higher bar for how new your development environment needs to be...

[AdamWill]

Gonna close this as the PR was definitely on the wrong track. If anyone feels strongly about putting setup_requires = ["setuptools_scm"] in setup.py , please open a PR for that instead...