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
At the moment, we register SHAs for GraalVM itself, but as of the latest GVM releases, not for individual components. Instead, we rely on gu to download those components.
This may introduce hermeticity issues, so we should figure out a better way.
Alternatives under consideration:
1) Download installable JARs and install them manually with gu
This is the approach taken before. It's safe/hermetic and rather optimal for downloads because there's nothing to figure out. On the other hand, when this was one component it was cumbersome, and now that there are like 5 components, it would grow to a point of being unmanageable. Plus, with GVM releases accelerating and users authoring their own components, we'll need to provide a mechanism later anyway with better APIs.
It's also worth noting that guis under deprecation, further mitigating any benefits to this approach.
2) Offer custom components attr, and wait for Maven transition
Offer an attribute like custom_components, which pulls JAR components or something from other repositories. This way, users could provide their own custom components if needed; how this would work mechanically is unclear. In the transition to deprecate gu, the equivalent assets will mostly be hosted on Maven Central, so we can provide hermetic access via rules_jvm_external.
The text was updated successfully, but these errors were encountered:
At the moment, we register SHAs for GraalVM itself, but as of the latest GVM releases, not for individual components. Instead, we rely on
gu
to download those components.This may introduce hermeticity issues, so we should figure out a better way.
Alternatives under consideration:
1) Download installable JARs and install them manually with
gu
This is the approach taken before. It's safe/hermetic and rather optimal for downloads because there's nothing to figure out. On the other hand, when this was one component it was cumbersome, and now that there are like 5 components, it would grow to a point of being unmanageable. Plus, with GVM releases accelerating and users authoring their own components, we'll need to provide a mechanism later anyway with better APIs.
It's also worth noting that
gu
is under deprecation, further mitigating any benefits to this approach.2) Offer custom components attr, and wait for Maven transition
Offer an attribute like
custom_components
, which pulls JAR components or something from other repositories. This way, users could provide their own custom components if needed; how this would work mechanically is unclear. In the transition to deprecategu
, the equivalent assets will mostly be hosted on Maven Central, so we can provide hermetic access viarules_jvm_external
.The text was updated successfully, but these errors were encountered: