-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for redis built-ins #114
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks pretty good just skimming the code, thanks for the contribution!
Because we don't have any robust testing of (any of the) builtin standards –and because I don't personally have any experience with Lua stuff in Redis– before I merge this I'd like to hear from somebody else that does have experience that can test it and give a thumbs up.
To that end do you happen to know somebody you can ping to test this? I can help them with local or CI based workflows to test a dev version if somebody has Lua code to run it on and see if it does what is expected.
Sure, I've verified the PR version on our CI system. I will find someone to confirm. |
|
I don't think there is a good way to denote that difference since at linting time we don't have any context about how it is intended to be run. I would suggest either just including both in all the variants of the standard, or including neither and expecting people to add them on via an extension (similar to how |
I'm not 100% I like it yet, but for the Pandoc builtin I'm working on now (over in #115) I tried splitting up the rules based on the 3 possible scopes: filters, readers, and writers. I then stuffed all three into an umbrella Do you think that sort of split makes sense for this? Again I don't have any idea what the Redis runtime scope(s) are or whether there is really enough of a difference between "scripts" and "functions" for separate rules to matter. |
(By the way don't worry about the LuaJIT test failures, the GH Action we're using is known-broken at the moment because the LuaJIT project moved some cheese.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will need a couple lines updated in docsrc/cli.rst
documenting the new builtins.
I'm not sure myself. I am unsure whether some projects use both redis functions and redis scripts. I do like the usability of the current situation. Perhaps an enhancement if requested? If it is required now, I can commit some time soon to splitting out the errant declarations. Scripts
Functions
UPDATE:
I think I do prefer the original (unified) format, but if there is a use case for this, it is definitely more flexible. |
Can Redis be compiled with a different base version of Lua? Or are there any Redis forks that allow it to be compiled with a user supplied Lua VM, e.g. the system default one? I'm trying to figure out whether including But I also haven't merged it yet because I'm not 100% in that choice. In general most of the builtins in Luacheck just target the latest version (c.f. |
This PR adds support for a builtin set of standards matching redis v5, v6 and v7.