mlflow dependency prevents test requirements from installing on Windows

[space-nuko]

Describe the bug

I want to run the pytest tests on Windows, but I can't install the requirements:

ERROR: Could not find a version that satisfies the requirement pywin32==227 (from docker==5.0.3->-r test/requirements.txt (line 65)) (from versions: 302, 303, 304, 305)

Long story short, this is caused by an old version of the docker package pinning a version of pywin32 that isn't compatible with Python 3.10 (and has security vulnerabilities!): docker/docker-py#2902

...and this version of docker is added as a transitive dependency by mlflow:

gradio/test/requirements.txt

Lines 65 to 66 in 19eaafb

	docker==5.0.3
	# via mlflow

...and mlflow later updated their dependencies to relax the docker version requirement but mlflow hasn't been updated in gradio yet: mlflow/mlflow#6562

So I think mlflow in the test requirements should be updated.

Is there an existing issue for this?

• I have searched the existing issues

Reproduction

pip install -r test/requirements.txt on Windows

Screenshot

No response

Logs

N/A

System Info

19eaafb2, Windows Server 2022, Chromium

Severity

blocking all usage of gradio

[freddyaboulton]

Can you try bash scripts/create_test_requirements.sh and then pip install test/requirements.txt?

[space-nuko]

Same error (from git-bash)

$ bash scripts/create_test_requirements.sh
Creating test requirements...
It's recommended to run this script from a Unix-like system in Python 3.7 (or higher) environment.
Collecting pip-tools
  Using cached pip_tools-6.12.3-py3-none-any.whl (52 kB)
Requirement already satisfied: pip>=22.2 in c:\users\a\build\gradio\venv\lib\site-packages (from pip-tools) (22.2.2)
Requirement already satisfied: setuptools in c:\users\a\build\gradio\venv\lib\site-packages (from pip-tools) (63.2.0)
Collecting build
  Using cached build-0.10.0-py3-none-any.whl (17 kB)
Requirement already satisfied: click>=8 in c:\users\a\build\gradio\venv\lib\site-packages (from pip-tools) (8.1.3)
Collecting wheel
  Downloading wheel-0.40.0-py3-none-any.whl (64 kB)
     ---------------------------------------- 64.5/64.5 kB 1.8 MB/s eta 0:00:00
Requirement already satisfied: colorama in c:\users\a\build\gradio\venv\lib\site-packages (from click>=8->pip-tools) (0.4.6)
Collecting pyproject_hooks
  Using cached pyproject_hooks-1.0.0-py3-none-any.whl (9.3 kB)
Requirement already satisfied: tomli>=1.1.0 in c:\users\a\build\gradio\venv\lib\site-packages (from build->pip-tools) (2.0.1)
Requirement already satisfied: packaging>=19.0 in c:\users\a\build\gradio\venv\lib\site-packages (from build->pip-tools) (23.0)
Installing collected packages: wheel, pyproject_hooks, build, pip-tools
Successfully installed build-0.10.0 pip-tools-6.12.3 pyproject_hooks-1.0.0 wheel-0.40.0

[notice] A new release of pip available: 22.2.2 -> 23.0.1
[notice] To update, run: python.exe -m pip install --upgrade pip
WARNING: the legacy dependency resolver is deprecated and will be removed in future versions of pip-tools. The default resolver will be changed to 'backtracking' in pip-tools 7.0.0. Specify --resolver=backtracking to silence this warning.
  ERROR: Could not find a version that satisfies the requirement pywin32==227 (from docker==5.0.3->mlflow==1.27.0->-r requirements.in (line 7)) (from versions: 302, 303, 304, 305)

[freddyaboulton]

Can you do pip install test/requirements.in and see what happens?

[space-nuko]

I got it to work by deleting the test/requirements.txt first before running create_test_requirements.sh, it seems like that file is versioned so it should be updated in the repository. Should that script delete the requirements.txt first also?

[freddyaboulton]

Yes feel free to make both of those modifications and create a PR!

Thank you

[abidlabs]

I think we should also just delete /test/requirements.txt but to pin the versions of all of our test packages that are currently listed in /test/requirements.in. That way, we have the benefit of getting a stable test environment by pinning the high-level packages without needing to pin all of the dependencies individually. Thoughts?

[freddyaboulton]

The counterargument is that I've seen cases where dependencies of dependencies update and break the build or cause a test to mysteriously fail.

[abidlabs]

Ah yeah makes sense

[space-nuko]

Looks like not pinning won't work for 3.7 tests, it looks like contourpy's latest version only accepts Python >= 3.8

Not to mention, 3.7 is EOL in June of this year