Support Distributions With All Native Libraries

[dw-genesys]

Describe the feature

Rather than always relying on an os-detector (which isn't suitable for using valkey-glide in a library,) it should be possible to depend on some "universal" version of valkey-glide Which includes all of the native libraries and chooses the correct ones at runtime. The previous suggestion I've received is to just add dependencies on each classifier (I'm using glide in Java) however when doing that the library can't necessarily find the correct native netty libraries.

Use Case

From what I can tell, the current best practice is to use an os-detector plugin in your build system to choose the correct classifier at build time. This runs into a couple of problems:

• Building a library on top of valkey-glide without the valkey-glide classifiers "infecting" my library.
• Build servers with a different OS/Arch than what will be used in production.

Both of these interfere with my use case. I was putting valkey-glide into a library which would be reused across multiple services which are deployed across several architectures, meaning that the library would then have to be classified based on os+arch to have the right native libs. The second problem is that the build server may not match the production server: if my build server is x86 I can't deploy to arm servers, for example.

Proposed Solution

Add a build with a "universal" (or something similar) qualifier which includes all of the native libraries and chooses the correct one at runtime.

Other Information

No response

Acknowledgements

• [ ] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

Client version used

2.0.1

Environment details (OS name and version, etc.)

In my specific case Ubuntu 24.04, but the problem occurred with Amazon Linux 3 aarch64

[Yury-Fridlyand]

dup of https://github.com/valkey-io/valkey-glide/discussions/3179

[asafpamzn]

Thanks @dw-genesys for reaching out. It sounds reasonable. @Yury-Fridlyand can you please provide a rough size estimation for this effort and based on it we can prioritize. @yipin-chen FYI

[dw-genesys]

Hey @Yury-Fridlyand do you want this closed out then, or open since it's a feature request vs idea?

[yipin-chen]

Hi @dw-genesys I would like to keep this issue open as a feature request. Based on Yury's rough estimations, this is going to be a breaking change with maybe 3 to 4 weeks of efforts. At this moment, I don't have the timeline for the next major release.

[dw-genesys]

No worries! I was just evaluating Glide at the moment. This doesn't affect anything in production or similar.

[jamesx-improving]

I'm not sure on the breaking change claim by @Yury-Fridlyand , please elaborate a bit. If we are talking about the removal of classifier from end user's gradle/maven file, I think we can actually keep the existing platform-specific jars in new versions, only add the platform-agnostic jar as one more option, if that's possible.

If this could be a non-breaking change, we could consider this one in the next minor release, like 2.2, which will make it happen way sooner.

[jamesx-improving]

Will list this feature request as 2.2 candidate for now. We will evaluate all 2.2 candidates after we released 2.1.

[github-actions[bot]]

This issue is inactive for 90 days, hence marked as stale, if the issue is still relevant please perform some activity