Update tensorrt-cu12-libs Package to Use Metadata 2.2 or Later for Improved Dependency Resolution
#4352
Comments
|
I'm happy to try and bump the setuptools version. It looks like it's encoded in |
LeoZDong
added
Module:OSS Build
kevinch-nv
added
Feature Request
|
These wheels are published internally. I'll open up a request internally for this. |
This package
It's unclear how this would work on bare metal using a Mac based on arm64 since we only have Linux x86 and Linux ARM SBSA packages available. Can you be sure it's not unable to find the required dependencies because it's simply not available? |
|
I just tried your repo (running the commands manually so I could debug if needed) and it works for me on Fedora 41 (CPU: AMD Ryzen 9 5900x). I'm using the |
|
Works with the Dockerfile you provided with the output I would expect to see. |
|
Thanks for trying out the examples @zeroepoch 😊 From @charliermarsh in issue astral-sh/uv#11363
In your first example #4352 (comment), as However, with the command If I don't explicitly request I hope this clarifies things. |
|
Broadly, the goal here is to enable tools to resolve dependencies for these platforms in a way that's decoupled from being able to build or install the wheel. In uv, for example, we generate a lockfile that works across platforms; so even if a The initial thought here was that you could upgrade to Metadata 2.2, then declare the dependencies directly in the stub package. That way, tools could get the |
|
I think there is context missing here and why this package is explicitly different. The reason the build package is called wheel-stub is because it's a shim for the real package. If you look inside the source package the entire build depends on sending metadata to the wheel-stub package. Wheel-stub fetches this data from the target package on another index to collect the new metadata. I would say this is by design to allow wheel-stub to be generic and at the same time allow us to make installing packages larger than 1GB close to as seamless as if they were natively hosted on pypi.org. Let me check with the authors of wheel-stub to see what they think about this issue. |
|
👍 I think I understand the stub design, though I believe the question is still relevant: is it possible to allow users to query for the package metadata without being on a platform that has a compatible wheel? As-is, the build step (which is necessary to extract the metadata) errors out if it can't find a compatible wheel (unless I'm mistaken?); but in these workflows, you're not actually looking to install a compatible wheel, you're just attempting to resolve the dependencies. |
|
@charliermarsh that makes sense. More flexibility is always better than less if we can enable it. I'm starting a conversation internally to see what the options are. |
|
@charliermarsh I have two broad thoughts on this: If wheel-stub implements I think there is also a wider issue of platform specific sdists gated behind platform specifiers and locking. You cannot be sure that an sdist will build on all platforms, so there are failure modes here which are important. But that would be a better fit for the uv issue tracker, perhaps we can take this discussion there. |
|
Thanks @emmatyping-nv (and hi)! Yeah, support for I guess the question might be moot, since if the metadata isn't consistent across platforms, then users will have a rough time using it with uv regardless. |
|
@charliermarsh hi! :) Yeah, wheel-stub doesn't currently work with wheels that have divergent metadata across platforms. This could lead to incorrect dependencies being resolved, but there's not much to be done about it. I can only generate one sdist. Perhaps given all of the wheels I could do something clever with environment markers. I've opened wheelnext/wheel-stub#21 to track that. |
Description
I am experiencing an issue with the
tensorrt-cu12-libspackage available on PyPI. Specifically, the package does not publish any wheels (as seen here), and the source distribution uses Metadata 2.1. This older metadata version lacks essential information that modern package management tools rely on for dependency resolution.When I use tools like uv to manage dependencies, they attempt to build the
tensorrt-cu12-libspackage because they cannot read the required metadata without building the package. This leads to build failures unfortunately.Updating the
tensorrt-cu12-libspackage to use Metadata 2.2 or later by employing the latest version ofsetuptoolsduring package creation would allow tools to read the metadata without building the package. This change would improve dependency resolution and prevent build attempts on unsupported platforms.Environment
TensorRT Version: 10.8.0.43
NVIDIA GPU: Not applicable (issue occurs on systems without NVIDIA GPUs)
NVIDIA Driver Version: Not applicable
CUDA Version: 12.x
CUDNN Version: Not applicable
Operating System:
python:3.12-slim-bookwormPython Version: Python 3.12.9
TensorFlow Version: Not applicable
PyTorch Version: 2.6.0
Bare Metal or Container: Both bare metal and Docker containers
Relevant Files
A minimal reproducible example (MRE) is available here:
These repositories contain
pyproject.tomlfiles that specifytensorrt-cu12-libsas an optional dependency.Steps To Reproduce
Using Optional Dependencies (Extras)
Clone the MRE repository:
git clone https://github.com/validatedev/uv-tensorrt-extradep-issue-mre.git cd uv-tensorrt-extradep-issue-mreAttempt to synchronize dependencies for an extra that does not include
tensorrt-cu12-libs(e.g.,macos):Observe that
uvtries to buildtensorrt-cu12-libseven though it's not part of themacosextra. The build fails with an error similar to:Observe that
uvtries to buildtensorrt-cu12-libseven though it is not requested.Using Dependency Groups
Clone the MRE repository:
git clone https://github.com/validatedev/uv-tensorrt-groupdep-issue-mre.git cd uv-tensorrt-groupdep-issue-mreAttempt to synchronize dependencies for a group that does not include
tensorrt-cu12-libs(e.g.,macos):Observe that
uvtries to buildtensorrt-cu12-libs. The build fails with an error.Error Output
uvtries to buildtensorrt-cu12-libseven though it is not requested.Commands or Scripts:
uv sync --extra macosuv sync --group macosdocker build -f linux-cpu.Dockerfile -t uv-test-extra .docker build -f linux-cpu.Dockerfile -t uv-test-group .Have you tried the latest release?
Yes, the issue persists with the latest release of TensorRT.
Can this model run on other frameworks?
Not applicable. The issue is related to package metadata and dependency resolution, not model execution.
Suggested Solution
Please consider updating the build process for
tensorrt-cu12-libsto use the latest version ofsetuptools, which generates Metadata 2.2 or later. This update would include the enhanced metadata within the source distribution, allowing tools to read dependency information without building the package.This change would improve compatibility with modern package management tools and prevent unnecessary build attempts on unsupported platforms.
Linked issue on repository uv: astral-sh/uv#11363
The text was updated successfully, but these errors were encountered: