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
lua: add withPackages function #54460
Conversation
Please unbreak LuaJIT evaluation back… |
So I am running locally the command from ofborg's readme with -vvvvv in order to diagnose the issue
but it fails with
@grahamc any idea on how to properly debug what part of the code is responsible for the error (like tracing the name of the function etc.) |
ok found the problem @7c6f434c could you have a look at the overall PR please? The shell script might need some changes/cleanup. I think I should rebase it on staging (what is staging-next ?). |
cd - | ||
} | ||
|
||
addEnvHooks "$hostOffset" startLuaEnvHook |
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.
Won't this add paths without checking in luaPathsSeen
?
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.
luaPathsSeen is effective when using the wrapper. The setup-hook is a bit different. With a naive version adding every possible folder for any package, it could end up too long. The version thus checks if the folder exists and only in that case it will add it to LUA_PATH. The "requiredLuaModules" calls unique
function so it should prevent duplicates from appearing.
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.
Are these called for requiredLuaModules
or for buildInputs
, though?
(Also, is there a reasonable way to just use wrappers during normal builds, to reduce code duplication, as well as confusion because of inexact duplication?)
(also, if luaPathsSeen
is not relevant for this file, why the comment mentions it?)
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.
Do you know if any duplication happens in case of multiple buildInputs propagate the same path?
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.
I've added a check against duplicates but this hook is run when building user environments so IIRC it is run only on the environment folder.
Re: target branch — I think if building |
lua and torch packages are usually fast to compile so master should be fine IMO. Rest assured that should any problem arise I will promptly fix them as I would like to follow up with other PRs as I described in the first updated post of #33903 |
First step towards more automation similar to the haskell backend. Follow up of NixOS#33903
I removed the luaWrap for now as it doesn't look necessary for now, and what I want to do first is to update the packages so that they use lua environments. It will make my other changes easier to rebase/submit. |
Nice, GitHub shows me the list of changes including a file that has empty diff. What the… convenient and consistent UI. I like the current version much better; I am not sure if handling repeated buildInputs in the shell code is worth the effort (maybe we could just see how it goes). Do I understand correctly that you expect this version of interpreter packages to stick for a while? I guess if this part is stable, I could reread it once more and merge it… |
check for duplicate as well.
Apart from merging the lua5.1/5.2/5.3 interpreters into one - which is low priority for me - my next steps would be: In terms of building, I will need to reintroduce a luaWrap (needed by some programs) but having the withPackages already available in nixos-unstable makes developement easier (and upgrade of some packages possible) so I am looking forward to this being merged. |
# export only if the folder exists else LUA_PATH grows too big | ||
if [ ! -d "$topDir" ]; then return; fi | ||
# check for duplicate | ||
if [[ $LUA_PATH = *"$pattern"* ]]; then return; fi |
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 check requries that patterns cannot be substrings of each other (which is true; not sure if worth a comment); but shouldn't either the variable to check depend on varName
or ;$LUA_PATH
just be checked against ;$topDir/
?
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.
right it should be topDir/$pattern, let me fix it, At the same time, I never had any trouble with duplicate buildInputs so I am tempted to just remove the line.
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.
ha no sorry pattern already contains the basefolder so it should be ok as is. I got confused because pattern don't have the same meaning in addToLuaSearchPathWithCustomDelimiter (absolute path) and addToLuaPath (relative path).
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.
I am OK with dropping.
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.
What I meant is that if ;$LUA_PATH
contains ;$topDir
we know that the bsae directory has been processed already.
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.
ok I've dropped the check and renamed pattern to abs(olute)Pattern to make it easier it has a different meaning. No need to troll myself.
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.
checking just against topdir would not be enough since several patterns are checked against the same topdir. The first matching pattern would discard others while they may be valid as well.
also makes clearer that in one case pattern is a full path while in the other it is relative.
@GrahamcOfBorg build love_11 luaPackages.luarocks luaPackages.luarocks-nix luaPackages.http |
GitHub: «10 checks passed» — that's counting only eval checks after I intentionally waited for a build to pass. Sigh. |
Cross-ref: #55345 |
First step towards more automation similar to the haskell backend.
Extracted from #33903 to make it easier to review.
Motivation for this change
I want to be able to create lua environments with lua.withPackages().
If some things appear awkward, more context at #33903 can help or just ask and I will try to answer if I can. I started this 1 year and half ago with no nix knowledge so some things can be improved (I would like to have a lua
lib
component as haskell does, my shell hooks might not be the best) but it kinda works.Something I did not dare do is merge the three lua 5.1/ lua 5.2 /lua5.3 interpreters into one which would remove some duplication. If I have the greenlight I want to do it.
You can test with sthg like:
NIX_PATH="nixpkgs=/home/teto/nixpkgs2:$NIX_PATH" nix-shell -p 'lua5_3.withPackages(ps: [ ps.lpeg ps.cqueues ])'
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)