rapidsai/miniforge-cuda is deprecated

[jameslamb]

Description

Opening this issue because I noticed that this project is using rapidsai/miniforge-cuda:

ml/Dockerfile.arm

Line 20 in cacaf3c

FROM rapidsai/miniforge-cuda:25.12-cuda13.0.1-base-ubuntu24.04-py3.13

That image is now deprecated... the upcoming RAPIDS 26.02 release will be the last one to update it:

• [RFC] deprecate and eventually remove miniforge-cuda? rapidsai/ci-imgs#345
• https://docs.rapids.ai/notices/rsn0057/

Some Options

To keep up with newer images as we add support for Python versions, CUDA versions, operating systems, etc., the easiest replacement is probably to switch to rapidsai/ci-conda, which will be supported indefinitely. That image contains everything rapidsai/miniforge-cuda has, plus a few extra things for use in RAPIDS CI (like command-line tools for some CI services).

If that's too big or otherwise doesn't suit your needs, it may be worth exploring directly relying on nvidia/cuda images and using something like micromamba to set up conda. I've given a minimal example of that at https://docs.rapids.ai/notices/rsn0057/

Notes

I'm one of the maintainers of the rapidsai/miniforge-cuda images (https://github.com/rapidsai/ci-imgs) and of rapidsai/notebooks (https://github.com/rapidsai/docker). I'll stay subscribed to this issue, please @ me here with any questions and I'll try to help.

[cboettig]

Thanks for this, super helpful. I'll take a go to migrate over to one of these solutions. Really appreciate your work on these!

Actually would really appreciate your insight on one issue here -- JupyterHubs (not jupyterlab) typically expect/require the default user to be UID 1000. The rapidsai/miniforge-cuda images have the default user for the rapids conda env as UID 1001. You can see some shenanigans I've done here in staged builds to hack around this, but staged builds make the collection too large to build on a GitHub runner and just feel cludgy. (Of course, doing a chmod or such to change UID effectively doubles the image size since layers are immutable). Any chance rapidsai/ci-conda setup could allow the rapids environment to run for UID 1000? (e.g. in addition to the 1001 user?) Happy to open an issue if that's not too niche a request... JupyterHubs are the default deploy mechanism for a lot of us here at Berkeley and in academic clouds in general (like NRP or 2i2c).

[cboettig]

@jameslamb just wanted to ping you on this.

I see that most of /opt/conda in rapidsai/ci-conda image is placed in the conda group, but some files are not. This prevents the exiting ubuntu (uid 1000 user) from installing into the conda env even after I add them to the group.

Note that this isn't something I can fix easily on our end because of immutable layers in docker, a chmod would nearly double the image size.

Do you think we could get this addressed upstream or is there a better solution?

Thanks so much!

[cboettig]

For now, the I just have the Dockerfile fix the group permissions on only those files in /opt/conda that seem erroneously to belong to root:root instead of root:conda on the rapidsai/ci-conda, https://github.com/rocker-org/ml/blob/master/Dockerfile#L26-L29

This adds about 200 Mb but is better than duplicating the entirety of /opt.

[jameslamb]

Just commenting so you know I'm not ignoring this... this is not something I'll be able to answer soon. It'll take a bit of investigation into why those images do the things they do with users and permissions, and what the impact of changing that behavior would be.

There's a similar tracking issue over in rapidsai/docker#762 for the rapidsai/base and rapidsai/notebooks images (which are intended for the usecase "run RAPIDS workflows", unlike rapidsai/ci-conda which is used in RAPIDS own continuous integration). You may want to subscribe to notifications on that.