Skip to content
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

Merged
merged 3 commits into from Jan 30, 2019
Merged

lua: add withPackages function #54460

merged 3 commits into from Jan 30, 2019

Conversation

teto
Copy link
Member

@teto teto commented Jan 22, 2019

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
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@7c6f434c
Copy link
Member

Please unbreak LuaJIT evaluation back…

@teto
Copy link
Member Author

teto commented Jan 23, 2019

So I am running locally the command from ofborg's readme with -vvvvv in order to diagnose the issue

$ curl -o outpaths.nix https://raw.githubusercontent.com/NixOS/ofborg/released/ofborg/src/outpaths.nix
$ GC_INITIAL_HEAP_SIZE=4g nix-env -f ./outpaths.nix -qaP --no-name --out-path --arg checkMeta true -vvvvv > out-paths

but it fails with

instantiated 'source' -> '/nix/store/25pdni30v75m9b85dygai4yvw4ydc3h4-source.drv'
processing attribute 'stdenv'
processing attribute 'strictDeps'
processing attribute 'system'
processing attribute 'userHook'
instantiated '9pfs-20150918' -> '/nix/store/4h2sk33qpk3hjap8mkjr0j1nixg0ynr6-9pfs-20150918.drv'
evaluating attribute '__splicedPackages'
error: out of memory

@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.)

@teto
Copy link
Member Author

teto commented Jan 24, 2019

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 ?).

@teto teto mentioned this pull request Jan 24, 2019
21 tasks
cd -
}

addEnvHooks "$hostOffset" startLuaEnvHook
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?)

Copy link
Member

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?

Copy link
Member Author

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.

@7c6f434c
Copy link
Member

Re: target branch — I think if building lua*Packages and torch*Packages takes reasonable time locally, it can go to master; otherwise yes, staging is better.

@teto
Copy link
Member Author

teto commented Jan 24, 2019

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
@teto
Copy link
Member Author

teto commented Jan 30, 2019

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.
Could you have another look please ?

@7c6f434c
Copy link
Member

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.
@teto
Copy link
Member Author

teto commented Jan 30, 2019

Do I understand correctly that you expect this version of interpreter packages to stick for a while?

Apart from merging the lua5.1/5.2/5.3 interpreters into one - which is low priority for me - my next steps would be:
1/ to make some packages (neovim/mpv/awesome mostly) depend on withPackages.
2/ Introduce buildLuarocksPackage and the "generated" packages ecosystem. I had first intended to completely replace the current infrastructure but in #33903, I was advised to deploy my changes under a different name to ease upstreaming.

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
Copy link
Member

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/ ?

Copy link
Member Author

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.

Copy link
Member Author

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).

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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.
@7c6f434c
Copy link
Member

@GrahamcOfBorg build love_11 luaPackages.luarocks luaPackages.luarocks-nix luaPackages.http

@7c6f434c 7c6f434c merged commit c4519cf into NixOS:master Jan 30, 2019
@7c6f434c
Copy link
Member

GitHub: «10 checks passed» — that's counting only eval checks after I intentionally waited for a build to pass. Sigh.

@vcunat
Copy link
Member

vcunat commented Feb 6, 2019

Cross-ref: #55345

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants