Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Issue]: Tensile should not be vendored #1396

Open
bgamari opened this issue Nov 27, 2024 · 2 comments
Open

[Issue]: Tensile should not be vendored #1396

bgamari opened this issue Nov 27, 2024 · 2 comments

Comments

@bgamari
Copy link

bgamari commented Nov 27, 2024

Problem Description

It appears that hipBLASLt depends upon Tensile. However, instead of recognizing this fact, the dependency is ignored by the documentation and is instead vendored.

Vendoring of dependencies creates untold headaches for distributors as the packager needs to:

  • identify the implicit dependency
  • sort out what version of the dependency the package expects
  • figure out how to furnish the dependency in a way that works with whatever bespoke mechanism the package has developed
  • continually maintain all of the above as the package and its dependency evolve

For this reason, vendoring of dependency is highly discouraged. If hipBLASLt depends upon Tensile then there is a proper way to do so: advertise the dependency in the readme, and discover it via the usual dependency discovery mechanisms.

Operating System

Any

CPU

All

GPU

Other

Other

this is a packaging issue and not hardware specific

ROCm Version

ROCm 6.2.3, ROCm 6.2.2, ROCm 6.2.1, ROCm 6.2.0, ROCm 6.1.2, ROCm 6.1.1, ROCm 6.1.0, ROCm 6.0.2

ROCm Component

hipBLASLt

Steps to Reproduce

No response

(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support

No response

Additional Information

No response

@IMbackK
Copy link

IMbackK commented Nov 28, 2024

tensilelight in this repo is a hard fork from the tensile of rocblas, its not so mutch a vendored tensile as it is something else entirely

@bgamari
Copy link
Author

bgamari commented Nov 28, 2024

Thanks for the clarification. Nevertheless, it would be appreciated if this project (and ROCm projects more broadly) would make less use of build-time fetching of dependencies as this greatly complicates packaging. Specifically, many packaging policies strictly prohibit fetching of further resources from the internet. The source distribution (e.g. git repository or source tarball) must include everything necessary to build the the package. Many distributions go even further than this, prohibiting usage of vendored dependencies entirely. This is generally out of concern for security, auditability, and maintainability.

If the dependency is tightly-coupled to hipBLASLt then consider turning it into a git submodule. If not then make it a proper dependency.

I understand the introduction of dependency-fetching logic is often made with the good intention of making users' lives easier, but it generally makes packagers' lives harder, not easier. If such logic is still desired for end-users then the package's installation documentation should clearly describe how such logic can be disable and how the dependencies can be furnished via traditional means.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants