You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, anything using rust that doesn't use the cargo*.py easyblocks most certainly already doesn't work, or won't work in the near future.
Retroactively fixing them is hard; the cargo lock and such does not account for compiler versions, and finding the old package list or just a ton of tedious unrewarding work that I'm certainly not willing to do.
We should clean all of these out, replace with newer versions if needed/possible.
List that I find are:
p/polars/polars-0.15.6-foss-2022a.eb would also affect infercnvpy-0.4.2-foss-2022a.eb
a/alevin-fry/alevin-fry-0.6.0-GCCcore-10.3.0.eb
a/alevin-fry/alevin-fry-0.4.3-GCCcore-11.2.0.eb
l/Longshot/Longshot-0.4.3-GCCcore-10.2.0.eb
l/librsvg/librsvg-2.51.2-GCCcore-10.3.0.eb (unsure, but they do use the Rust as a build dep)
l/librsvg/librsvg-2.52.8-GCCcore-11.2.0.eb
l/librsvg/librsvg-2.55.1-GCCcore-11.3.0.eb
l/librsvg/librsvg-2.58.0-GCCcore-13.2.0.eb
l/libavif/libavif-0.9.0-foss-2020b.eb (unsure, these are really strange, using Rust as a runtime dep. For rav1e codec i assume? But why runtime dep...)
Doesn't really solve the issue with Rust and cargo easyblock, but there is at least now that fixes that strange runtime compiler dep: #20747
Both librsvg and libavif are troublesome, we'll have to think of another solution there, because I don't want to make some a bunch of extra easyblocks like "ConfigureMakeCargo" etc. Yuck. All they really need is the
crates support for unpacking the extra sources
a couple of environment variables which tells cargo how to build.
Not that easy to add to ConfigureMake/CMakeMake type blocks though...
So, anything using rust that doesn't use the
cargo*.py
easyblocks most certainly already doesn't work, or won't work in the near future.Retroactively fixing them is hard; the cargo lock and such does not account for compiler versions, and finding the old package list or just a ton of tedious unrewarding work that I'm certainly not willing to do.
We should clean all of these out, replace with newer versions if needed/possible.
List that I find are:
p/polars/polars-0.15.6-foss-2022a.eb
would also affect infercnvpy-0.4.2-foss-2022a.eba/alevin-fry/alevin-fry-0.6.0-GCCcore-10.3.0.eb
a/alevin-fry/alevin-fry-0.4.3-GCCcore-11.2.0.eb
l/Longshot/Longshot-0.4.3-GCCcore-10.2.0.eb
l/librsvg/librsvg-2.51.2-GCCcore-10.3.0.eb
(unsure, but they do use the Rust as a build dep)l/librsvg/librsvg-2.52.8-GCCcore-11.2.0.eb
l/librsvg/librsvg-2.55.1-GCCcore-11.3.0.eb
l/librsvg/librsvg-2.58.0-GCCcore-13.2.0.eb
l/libavif/libavif-0.9.0-foss-2020b.eb
(unsure, these are really strange, using Rust as a runtime dep. For rav1e codec i assume? But why runtime dep...)l/libavif/libavif-0.11.1-foss-2022a.eb
l/libavif/libavif-0.11.1-foss-2021a.eb
l/libavif/libavif-1.0.4-foss-2023a.eb
l/libavif/libavif-0.11.1-GCCcore-11.3.0.eb
g/gsutil/gsutil-5.10-GCCcore-11.2.0.eb
f/fastparquet/fastparquet-0.8.0-foss-2021b.eb
f/fastparquet/fastparquet-0.7.2-foss-2021a.eb
s/Safetensors/Safetensors-0.3.1-foss-2022a.eb
s/Safetensors/Safetensors-0.3.1-foss-2022a-CUDA-11.7.0.eb
t/tokenizers/tokenizers-0.12.1-GCCcore-10.3.0.eb
t/Transformers/Transformers-4.30.2-foss-2022b.eb
t/Transformers/Transformers-4.24.0-foss-2022a.eb
t/Transformers/Transformers-4.29.2-foss-2022a.eb
The text was updated successfully, but these errors were encountered: