valkey-io
[EPIC] Users oppinon needed - windows support for languages missing it.
To understand the need, I would be happy to hear from users. There are few approaches that can possibly be taken; some are addressing one language only, and some are addressing more. Each has its pros and cons. To make the right design decision, the team and I would like to understand how large the need is, and specifically per language, so we can make the decision that fits users' needs.
If you require Python, please add 😄, if Node, please add ❤.
If you have any additional data you can add, like whether you are speaking for a team, what the product you're working on is, whether you tried WSL, and why yes or no, and whether you chose another client because of that, please comment.
For tracking — we are aware of 6 requests, 2 for java and one for python, the others are unknown.
@liorsve @barshaul Python sync should support windows as well, as there's no UDS under the hood.
@Yury-Fridlyand Go should have windows support the three mentioned need rework for support because of UDS, the FFI languages have no reason to not support
I'm +1 for node.js (although dev only so idc about performance at all), but as far as go is relevant, current version of glide for go does not build, as there is type mapping mismatch between size_t -> long/long long and maybe more issues, but I did not get past these so far.
So it seems like iovalkey and valkey-go are way to go, which sucks a bit since it's always nice to start project with dependencies that won't be deprecated, but just my luck to start at this point in time.
I'm not going to create issue for this as windows is not officially supported so just for those curious, this is the error (multiple places):
github.com\valkey-io\valkey-glide\go\[email protected]\base_client.go:341:49: cannot use _Ctype_size_t(len(args)) (value of uint64 type _Ctype_size_t) as _Ctype_ulong value in variable declaration
I guess I'll have to dev in linux, but since my main app is windows focused, working on two machines or WSL is a bit cumbersome.
I'm +1 for node.js (although dev only so idc about performance at all), but as far as go is relevant, current version of glide for go does not build, as there is type mapping mismatch between size_t -> long/long long and maybe more issues, but I did not get past these so far.
So it seems like iovalkey and valkey-go are way to go, which sucks a bit since it's always nice to start project with dependencies that won't be deprecated, but just my luck to start at this point in time.
I'm not going to create issue for this as windows is not officially supported so just for those curious, this is the error (multiple places):
github.com\valkey-io\valkey-glide\go\[email protected]\base_client.go:341:49: cannot use _Ctype_size_t(len(args)) (value of uint64 type _Ctype_size_t) as _Ctype_ulong value in variable declarationI guess I'll have to dev in linux, but since my main app is windows focused, working on two machines or WSL is a bit cumbersome.
@jonathanl-bq
@ligazetom Hi, long on the FFI layer is in an open issue, I don't think there is more specific breaking except the long. We would fix those soon. It is not part of v2, but I think it will be fixed right after. But yes, you're right, those are problems that we pointed out.
In case you are trying to compile for now for self use, using explicit u64 type will fix it, and this is what we plan to do as for fixing it.
For me WSL is out of the picture. The client requires more control on what can be run on the device and requires all Windows machines.
Off to looking other libs then.
For me WSL is out of the picture. The client requires more control on what can be run on the device and requires all Windows machines.
Off to looking other libs then.
Hi, thanks for the feedback, and sorry we couldn't deliver what you need. Support for Windows is planned and being developed but still not introduced. Just to fully grasp my understanding, you are using node.js?
I've been using NodeJS and unfortunately struggling with Valkey Glide failing on Windows due to @valkey/valkey-glide-win32-x64-msvc not existing.
Was quite confused looking around and it doesn't seem like it's clearly marked on NPM or the GitHub README that Valkey Glide doesn't support Windows. You'd think that would be something that would be put in a banner at the top like:
⚠️
valkey-glidecurrently does not support Windows in all languages! We are currently working on adding Windows support, but currently do not have an ETA.
I guess I'll be using iovalkey instead until support is added, which is really a shame because I quite like the API of valkey-glide.
I'm also running into this issue when working locally on Windows (using nodejs). I've temporarily worked around it with the expectation that this would be resolved at some point, but it's a pain as it involves maintaining a bunch of hacked code locally just so I can get my applications to run. Would appreciate it if this could be made to work on Windows.
Close the issue. All Java Windows tests are passed.
How about for Node and Python which are also part of this issue (Node being the biggest one here)?
Asks for community opinion on what languages to support
Community: Python: 4 Java: 5 Node: ✨️ 25 ✨️
Adds Java support and closes the issue.
I appreciate that you don't have to provide us the features we ask for (or really anything else since this is open source and you dont owe us anything), but you did ask the community. Granted it may be a mistake to close this issue, but if not, that's pretty scummy.
Misunderstanding, the issue was closed since it was marked as part of the release for Java support and not separated into a different issue for the specific task.
If you have any additional data you can add, like whether you are speaking for a team, what the product you're working on is, whether you tried WSL, and why yes or no, and whether you chose another client because of that, please comment.
This is blocking me from finalizing valkey-glide first class support for layered-loader, because I cannot easily run it from my machine (and no, I don't really use WSL)
so yeah, would very much appreciate support for Node.js/Windows combo, which is pretty mainstream.
