Pass current machine's architecture to rapids-dependency-file-generator. #54
Conversation
There was a problem hiding this comment.
I totally support this! Just left one very small comment for consideration.
I also support not exposing configuration to turn this off... let's not add that complexity until we need it. Every RAPIDS CI job, DLFW builds, and devcontainers pass arch unconditionally to rapids-dependency-file-generator, I think it's safe to unconditionally pass it from here too.
| # RAPIDS projects all use "aarch64" to indicate arm architectures, | ||
| # but arm some systems (like the M1/M2/M3 Macs) report "arm64" | ||
| if plat == "arm64": | ||
| return "aarch64" |
There was a problem hiding this comment.
I'm fine with this for now, but it does feel like a bit of a hack. Technically platform.machine is probably not sufficiently discriminating between types of architectures in many cases, and in this particular case it is giving us a meaningful difference that we are choosing to ignore: our aarch64 dependency lists throughout RAPIDS are probably not valid on most Macs anyway. I'm comfortable with including this given that RBB is specialized enough for RAPIDS's needs that I don't expect anyone else to ever use it, but this line feels like a bit of a footgun in case anyone ever did try to.
There was a problem hiding this comment.
I am going to leave this as-is for now. I don't anticipate this causing issues. xref: #54 (comment)
This PR passes the current machine architecture to rapids-dependency-file-generator. This makes it possible to use arch-specific matrices in pyproject outputs.