[Feature Request] Modernize packaging: add support for uv + PEP518 + PEP621

[ojeda-e]

Is your feature request related to a problem? Please describe.
Installing dependencies currently relies exclusively on pip, which can be relatively slow and sometimes inconsistent across environments. One of the key dependencies is torch and torchvision, which are large packages that can take significant time to install with pip. This is not a problem per se, but installation and dependency management can be optimized, and in the process the project can modernize to comply with some PEP.

Describe the solution you'd like
I’d like to have a pyproject that supports environments managed with uv, since it offers faster and more reliable dependency installation than pip for both users and developers. As part of this, the project would adopt a pyproject.toml that complies with:
• PEP 518 (specifying build system requirements)
• PEP 621 (declaring project metadata)
This change would modernize the repository’s packaging infrastructure and improve the developer and user experience with uv.

Describe alternatives you've considered
A first step would be to comply with PEP 621 by specifying metadata in the pyproject.toml. Then include a uv.lock file for reproducible installations. The repository could continue supporting the existing setup.py for backwards compatibility, while offering uv as an optional or preferred path. It will offer flexibility to the user to choose between pip and uv as a dependency manager.

Additional context
I acknowledge that currently the repository uses setup.py and env vars that determine the versions of some dependencies (VALID_BUILD_TYPES = {"release", "nightly", "dev"} and BUILD_TYPE = os.environ.get("BUILD_TYPE", "dev"). Because of that, some changes may be needed in the CI/CD workflows or build infrastructure. One possible solution is to keep setup.py for legacy compatibility, but introduce pyproject.toml + uv support so users/devs can choose between the traditional method or the newer uv workflow.

I also recognize that there are probably reasons why this hasn’t been done before (for example backwards compatibility, build toolchain constraints, or CI integration), which I don’t personally know and the maintainers will know better than anyone else. But in any case I’m happy to help with this issue and collaborate with maintainers to make the repo compatible with uv and the PEP standards mentioned above.

[brian-dellabetta]

Hi @ojeda-e , we encourage use of uv for fast installation. Our setup.py is customized to handle the close coupling to compressed-tensors, for nightly vs release builds, but uv pip install llm-compressor or uv pip install -e /path/to/llm-compressor (when git cloned to your local drive) should both work accordingly.

uv.lock is valuable for reproducibility, and recommended for local development, but it is commonly gitignored (as vllm does here) for team projects.

[ojeda-e]

Thanks @brian-dellabetta, I had missed the uv.lock included in the gitignore, thanks for pointing that out.

I agree that the installation of llm-compressor can be done with uv pip install llm-compressor. However, I'd like to clarify that the feature request is to install the dependencies of llm-compressor with uv. For example, I'd like to:

• run uv venv -n llm-compressor to create my env.
• and then install the deps in my uv env with uv sync.
• or more specifically, to install the dev deps: uv sync --group dev.
• and even run tests with uv run pytest.

For example, when I try uv sync I get:

error: No `project` table found in: `my-path/llm-compressor/pyproject.toml`

which is an expected error, because the current pyproject.toml doesn't include the package metadata. To fix this error, the pyproject.toml would need to have a [project] table similar to this example. The same error is triggered when I run uv run pytest and the fix works for this too.

Our setup.py is customized to handle the close coupling to compressed-tensors, for nightly vs release builds, but uv pip install llm-compressor or uv pip install -e /path/to/llm-compressor (when git cloned to your local drive) should both work accordingly.

Yes, correct, I acknowledge that. And AFAIK, this functionality wouldn't be migrated to a pyproject.toml and the reason I suggested:

one possible solution is to keep setup.py for legacy compatibility, but introduce pyproject.toml + uv support so users/devs can choose between the traditional method or the newer uv workflow.

The feature request I’m describing is to make it possible to use uv to install the project’s dependencies and potentially optimize test runtimes. From my experience, running tests with uv can yield up to a 25% speedup, which is why I believe the project could benefit from it.