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

RFC: Turn cuda-python into a metapackage #105

Open
leofang opened this issue Sep 12, 2024 · 0 comments
Open

RFC: Turn cuda-python into a metapackage #105

leofang opened this issue Sep 12, 2024 · 0 comments
Assignees
Labels
RFC Plans and announcements

Comments

@leofang
Copy link
Member

leofang commented Sep 12, 2024

As we are making cuda a namespace package and creating subpackages such as cuda.core (#70) and cuda.bindings (#75), each of which may have its own version, it makes sense for us to rethink the package structure.

This RFC proposes a way to restructure the components so as to allow users to install only the components that are needed. As a result, we can make the existing cuda-python become a meta package depending on the individual components. Visualizing with the fact that we actively maintain two major-version branches (currently CUDA 11 & 12, so X=12 below), we have the following diagrams:

  • Before cuda.core beta release:
    cuda-python (X.Y.Z)          cuda-python (X-1.Y'.Z')
            \                          \
             \                          \
              v                          v
        cuda-bindings (X.Y.Z)       cuda-bindings (X-1.Y'.Z')
  • After cuda.core beta release:
            cuda-python (X.Y.Z)          cuda-python (X-1.Y'.Z')
            /         \                  /         \
           /           \                /           \
          v             v              v             v
    cuda.core --> cuda-bindings    cuda.core --> cuda-bindings
       (A.B.C)        (X.Y.Z)       (A.B.C)        (X-1.Y'.Z')

This RFC is not impacting existing users in anyway (apart from what's already outlined in #75). This is purely an implementation detail to users. However, this allows advanced users and libraries to have the freedom to choose if they need cuda-python, cuda.core or just cuda.bindings (the cuda-python today). We also allow a more complex dependency diagram to grow organically under cuda-python.

Please let us know if you have any thoughts or concerns. Thanks!

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

No branches or pull requests

1 participant