InternLM / lmdeploy

LMDeploy is a toolkit for compressing, deploying, and serving LLMs.
https://lmdeploy.readthedocs.io/en/latest/
Apache License 2.0
3.15k stars 281 forks source link

lock setuptools version in dockerfile #1770

Closed RunningLeon closed 2 weeks ago

RunningLeon commented 2 weeks ago

Motivation

Failed with lmdeploy check_env for latest setuptools==70.0.0, use setuptools==69.5.1 to fix it.

Traceback (most recent call last):
  File "/opt/py38/bin/lmdeploy", line 33, in <module>
    sys.exit(load_entry_point('lmdeploy', 'console_scripts', 'lmdeploy')())
  File "/opt/lmdeploy/lmdeploy/cli/entrypoint.py", line 37, in run
    args.run(args)
  File "/opt/lmdeploy/lmdeploy/cli/cli.py", line 195, in check_env
    env_info = collect_env()
  File "/opt/py38/lib/python3.8/site-packages/mmengine/utils/dl_utils/collect_env.py", line 73, in collect_env
    CUDA_HOME = _get_cuda_home()
  File "/opt/py38/lib/python3.8/site-packages/mmengine/utils/dl_utils/collect_env.py", line 25, in _get_cuda_home
    from torch.utils.cpp_extension import CUDA_HOME
  File "/opt/py38/lib/python3.8/site-packages/torch/utils/cpp_extension.py", line 28, in <module>
    from pkg_resources import packaging  # type: ignore[attr-defined]
ImportError: cannot import name 'packaging' from 'pkg_resources' (/opt/py38/lib/python3.8/site-packages/pkg_resources/__init__.py)

Modification

Please briefly describe what modification is made in this PR.

BC-breaking (Optional)

Does the modification introduce changes that break the backward-compatibility of the downstream repositories? If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.

Use cases (Optional)

If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.

Checklist

  1. Pre-commit or other linting tools are used to fix the potential lint issues.
  2. The modification is covered by complete unit tests. If not, please add more unit tests to ensure the correctness.
  3. If the modification has a dependency on downstream projects of a newer version, this PR should be tested with all supported versions of downstream projects.
  4. The documentation has been modified accordingly, like docstring or example tutorials.