Can't use third party packages after update...

[João A. Quinaglia]

I did everything as usual and read and reread this section in the manual... It just doesn't work anymore, even running eval $(luarocks path)...

Some info:

$ sile -e 'print(SILE.lua_version);os.exit()' 2> /dev/null
5.1

$ luarocks

Configuration:
   Lua:
      Version    : 5.1
      Interpreter: /usr/bin/luajit (ok)
      LUA_DIR    : /usr (ok)
      LUA_BINDIR : /usr/bin (ok)
      LUA_INCDIR : /usr/include/luajit-2.1 (ok)
      LUA_LIBDIR : /usr/lib (ok)

   Configuration files:
      System  : /usr/local/etc/luarocks/config-5.1.lua (ok)
      User    : /home/jodros/.luarocks/config-5.1.lua (ok)

   Rocks trees in use:
      /home/jodros/.luarocks ("user")
      /usr/local ("system")

$ luarocks list

Rocks installed for Lua 5.1 in /home/jodros/.luarocks
-----------------------------------------------------

config.sile
   dev-1 (installed) - /home/jodros/.luarocks/lib/luarocks/rocks-5.1

custom.sile
   dev-1 (installed) - /home/jodros/.luarocks/lib/luarocks/rocks-5.1

datafile
   0.10-1 (installed) - /home/jodros/.luarocks/lib/luarocks/rocks-5.1

lua-toml
   2.0-1 (installed) - /home/jodros/.luarocks/lib/luarocks/rocks-5.1

luafilesystem
   1.8.0-1 (installed) - /home/jodros/.luarocks/lib/luarocks/rocks-5.1

textual.sile
   dev-1 (installed) - /home/jodros/.luarocks/lib/luarocks/rocks-5.1

It was working fine before the update... Where the origin of this could be?

[Caleb Maclennan]

The output of luarocks list is showing things installed local to your user. SILE doesn't check that path by default. It checks the system installation paths (luarocks --global) and project local paths (equivalent of luarocks --tree ./lua_modules), but not the equivalent of luarocks --local which is what your installations are using.

You'll want to eval $(luarocks --local path) before running SILE to specifically add that location to the path variables.

Here is a handy command to see where SILE is actually looking for things:

$ sile -e 'SU.dump(pl.stringx.split(package.path, ";"));os.exit(0)'

The output of that should reflect changes you make to the environment via LUA_PATH, SILE_PATH, and others.

[João A. Quinaglia]

but not the equivalent of luarocks --local which is what your installations are using.

Well, that's weird for me, because I've always being using SILE packages this way and never had any problem so far! Never had to install them neither as global nor in the project's path in order to use their commands.

Even after have run eval $(luarocks --local path), the output of $ sile -e 'SU.dump(pl.stringx.split(package.path, ";"));os.exit(0)' doesn't show anything but those global and project paths.

And by the way, does it have anything to do with all those 15.0 changes?

[Caleb Maclennan]

This isn't something that should be different between v0.14.x and v0.15.x ... but certainly could be because the Lua interpreter and entire environment is a whole different ball of wax. I'm actually surprised your user --local installed Rocks were working in v0.14.x, I was unaware we'd made any provision for that. Are you sure you don't have the eval/luarocsk path stuff in your bashrc file or something like that so that it's in your environment by default? What was env | grep -i lua show?

I'll look into why manually running that eval isn't doing anything. It should but I haven't tested that scenario in a while.

[Caleb Maclennan]

Yes, we did kind of break this workflow. We're only responding to changes in the LUA_PATH environment variable at compile time, not at run time.

As a temporary work around you can first setup a link to what SILE expects as a project level rocks tree in your user directory, then leverage SILE_PATH:

$ cd ~/.luarocks
$ ln -s . lua_modules
$ export SILE_PATH="$HOME/.luarocks"

Thereafter of course the link will exist so you just need the one export before running SILE, but of course that's a dirty mess. I'll look into fixing this regression in a patch release sooner rather than later.

[Caleb Maclennan]

v0.15.3 should bring this workflow back to the way it was such that having LUA_PATH set at run time will make that the default starting point for everything, not whatever might have been detected at build time (which will still be used if nothing is set).

You can delete the symlink at ~/.luarocks/lua_modules if you created one and go back to what you had.