Include Luarocks in Hammerspoon.

[jasonm23]

Since Hammerspoon is using it's own Lua, I suggest we should also include luarocks.

The main reason for this is the fragmented support for Lua on homebrew. There's no easy way (that I know of) to install luarocks for 5.3 via homebrew at the moment, and there seems to be reluctance to provide deeper support, and to turn over Lua/homebrew to a (currently non-existent) lua community tap.

As a result, any config relying on installed rocks, was broken by the recent Hammerspoon/Lua 5.3 update, leaving people with difficulties upgrading.

Is there any advice to be had, for dealing with this, for the moment people have to install luarocks from source.

[cmsj]

Hmm, I didn't realise we'd broken luarocks users. That's not good!

I'm not opposed to shipping luarocks if there's no good alternative. I'd like to get some input from @asmagil though, as he has probably done the most work that is relevant here, imo.

[jasonm23]

Thanks Chris, @cmsj I've installed from source and it seems to be working apart from an inexplicable lack of an alert at startup. (jasonm23/.hammerspoon)

[jasonm23]

Ah, not so inexplicable my splash animation is now z-indexed above it due to the new arrangement stuff in hs.drawing.

[jasonm23]

off topic but maybe the hs.drawing api needs moveBack / moveForward or some such method name.

I think the alert will need a fix too, so that they behave as before and sit above drawn objects.

I'll open up a couple of issues.

[asmagill]

My understanding is that the brew luarocks has been removed as a separate install and is now builtin to the lua and lua53 packages... I know I had a little bit of a snafu when I updated one of them a while back and it complained about a package conflict until I removed lua, lua53, and luarocks completely and reinstalled just lua and lua53.

That said, I really haven't done much with Luarocks lately -- the ones I used the most are now part of hammerspoon or have something equivalent enough for my day-to-day needs.

I do think if we want to be able to provide a single app with everything needed for a complete Lua experience we probably should include luarocks, though, since it's expected and may not work cleanly with brew as it defaults to 52... I know I had to change makefiles to reference lua53, rather than lua (before we started including the .h files in the App).

I'll give it some thought, though the first question that comes to mind regarding luarocks is how would we want HS users to use it? Via the command line, as before? If so, then we'll need to be able to work around things like people who already have it through brew or a manual installation. If we want to provide our own interface (command line or other), then we run into some of the same considerations that led sdegutis to back off on promoting a specific package management system with Mjolnir...

On Jul 4, 2015, at 11:19 AM, Chris Jones notifications@github.com wrote:

Hmm, I didn't realise we'd broken luarocks users. That's not good!

I'm not opposed to shipping luarocks if there's no good alternative. I'd like to get some input from @asmagil though, as he has probably done the most work that is relevant here, imo.

—
Reply to this email directly or view it on GitHub #363 (comment).

[cmsj]

I was thinking as a first cut we could just have people run luarocks out of the application bundle, and configure it to install in ~/.hammerspoon/

[jasonm23]

@asmagill I installed lua53 via brew yesterday, and there was no luarocks.

I can install it by doing:

brew install lua
brew tap homebrew/versions
brew install lua53

Then I have 2 luas and perhaps another problem.

Since I don't have any other dependencies on Lua within either brew's installed-set or anything else, I decided to clean it out of brew /usr/local and just install Lua53 from source and then grab lua-rocks and make it too, to be in control of the install.

Of course now I have the Lua53 install via Hammerspoon's bundle and my compiled version, not really a big deal, but also quite confusing for some people to do this.

For the rest of my team I'd prefer to just keep this as simple as possible, not really for the human factor, but this is not really pleasant for configuring a bunch of machines.

[jasonm23]

@cmsj I think putting ...bin/luarocks in the ~/.hammerspoon folder and adding some documentation around it is probably a good idea. I'm not sure about adding ~/.hammerspoon to the path.

I don't know the ins-and-outs of luarocks configuration, and if it would be a headache to have multiple sets of rocks installed in different places.

I guess it will be a bit of a headache for those with an existing Lua based dev environment, Lapis, LOVE etc. However I haven't done the reading/experiments yet to know for sure.

[cmsj]

@jasonm23 I'm not sure that putting bin/luarocks in ~/.hammerspoon/ is a good idea - we'd have to start doing lots of lifecycle management where each different version of Hammerspoon you install/run would need to remove the luarocks binary and copy its own in. I tend to think that just having luarocks in our .app bundle and letting users symlink if they care to have it in $PATH, would be better.

[jasonm23]

@cmsj sounds reasonable.

[jasonm23]

NOTE: I rolled back my brew lua to 5.2 and completely removed 5.3 and updated hammerspoon is running ok.

Unless there are 5.3 requirements in Luarocks people use, there's no immediate problem.

[asmagill]

Off the top of my head, the 3 things you'll want to watch for in your rocks are as follows:

• Lua 5.3 has no bit32 library, though you can probably find one or write one fairly easily and as long as it is command identical, just do bit32 = require(..whatever..) in your init.lua
• Lua 5.3 makes a distinction between integer and number (float)... off the top of my head I don't think this should be an issue often with rocks, but if you're getting odd numerical results (a decimal where you expect an integer in output, for example), this would be what to look at
• rocks with compiled (C, C++, etc.) components probably won't work, as they'll be linked against liblua5.2, rather than 5.3... it might be possible to manually link them against the included luaskin framework of Hammerspoon, but then they wouldn't work with command-line lua...

I'm interested in hearing about your experiences with this as it goes along... so far, I've not heard about many setups with significant inclusion of luarocks, outside of lfs and inspect, which we include.

On Jul 16, 2015, at 10:00 PM, JasonM23 notifications@github.com wrote:

NOTE: I rolled back my brew lua to 5.2 and completely removed 5.3 and updated hammerspoon is running ok.

Unless there are 5.3 requirements in Luarocks people use, there's no immediate problem.

—
Reply to this email directly or view it on GitHub #363 (comment).

[jasonm23]

My inclusions are just Moonscript and Moses, which is unlikely to expand.

I might suggest that along with Moses, Moonscript is available to be required directly from hammerspoon... any thoughts on that?

[cmsj]

@jasonm23 I do see the value of Moonscript, but I continue to worry that its effect on Hammerspoon will be to fragment user configs and make it harder for people to share their ideas :/

[jasonm23]

It's only slightly more difficult to install the luarock and require "moonscript" than not having to do the luarock part.

I would posit that the very existence of moonscript already creates the fragmentation you are concerned about.

Also by removing artificial barriers it makes it easier to exchange ideas from both Lua and Moonscript configs.

I think anyone who really wants to use Moonscript is going to anyway. Including it in the bundle just cleans up any compatibility issues.

[cmsj]

@jasonm23 so am I reading this right that we should be ok and don't need to look further at adding luarocks?

[jasonm23]

If Moonscript is require-able directly from the ap bundle (along with Moses.) That would solve my issues.

LuaRocks being available from the bundle would be nice too, because it would remove some problems for people who (a) don't have Lua installed, or (b) have a different version installed.

I think providing LuaRocks in the bundle would be more of a help than not, perhaps going so far as to rename the bin to hammerrocks (just a thought, perhaps not a very considered one) to avoid conflicts.

Either way, I'm not sure this is ready to close, what do you think?

[cmsj]

If we were to ship LuaRocks, we'd not only have to rename it, but also relocate all of the places that it writes files, to avoid clashing with a separate installation of luarocks.

I'm a little worried about starting to collect Lua modules like moonscript/moses that are completely unrelated to OS X, so I think it would be best if they stayed outside Hammerspoon, so long as they can install and work via luarocks or dropping into ~/.hammerspoon/. Sorry!

[jasonm23]

Can't say I'm not disappointed but I understand.

Does this also mean you won't integrate just moses and moonscript?

They are fairly special cases. I don't think they would imply that it's fair game to include any other rocks directly into hammerspoon.

[cmsj]

Moses in particular is a bit tricky because we already have hs.fnutils (even if it's not as good), and a proposed replacement for it (hs.func).

I'd like to know if @lowne would prefer to include Moses than his hs.func :)

[jasonm23]

Surely it's better to just use Moses, it's the de-facto fn lib for Lua? It would also remove any need for WRI (wheel re-invention).

[lowne]

I didn't set out to reinvent the wheel, I just wanted fnutils to be correct, consistent and predictable (see #455 and #488) because it's used in our existing codebase and can cause subtle bugs. This said, I'm all for using a proven solution with a lot more functionality, if only because it means less code to maintain.

Obstacles:

1. fixing the existing codebase won't be just a find-and-replace-while-keeping-your-eyes-open deal as there's no 1:1 mapping to fnutils; but I suppose I can handle it once I get acquainted with moses
2. no included collection object afaict, and that's quite handy; and if we start adding customisations downstream we're back at having code to maintain (it's arguably even worse with a foreign upstream)
3. I think @asmagill needed sorted iterators somewhere; I only had a cursory glance at moses but I'm sure there's a way to get that functionality (in a few steps at most)
4. documentation; I'm the one that stands to gain the most from switching to (or adding along) ldoc/luadocumentor since I use Eclipse LDT, but I haven't messed with the build scripts to get this done, and I have no intention of doing it anytime soon.

[jasonm23]

Sorry I didn't mean to sound so glib. My point was just for the team to avoid maintaining code that is shadowed by a stable, powerful, community alternative.

[jasonm23]

I could definitely look at the uses of fnutils and see if I can help out. Won't be immediate. But next weekend is likely.

[lowne]

avoid maintaining code that is shadowed by a stable, powerful, community alternative

As I said, in this case I can agree (although on the more general Roberto vs rest of the world issue of Lua community fragmentation, I tend to side with Roberto - but that's wholly OT)
About the problems I mentioned, fwiw, 1 and (I think) 3 can be handled, 2 I can live without, and 4 could be "solved" by just pasting, for the benefit of eager users, a nice url; but this seems to go against Hammerspoon's "batteries included" philosophy, if only tangentially, and at any rate it's not my call.

[lowne]

@jasonm23 Anyway, just out of curiosity, what do you use moses for that can't be done with fnutils/func?

[jasonm23]

Among other things, it has flatten, compact, difference, union, intersection, zip ... and so on.

My main suggestion though is that you avoid the use of a small homemade library, when there's an extensive higher-order / list processing library well used, supported, and maintained.

[asmagill]

+1 for moses. Most of the earliest uses of fnutils can, with minor changes, be made to work with it. It shouldn't be a massive code rewrite effort, just a lot of small ones.

The three I've added to fnutils: split, sortByKeys, and sortByValues can really go anywhere... and I've never been 100% comfortable with them in fnutils but there was really no where better. Outside of documentation (both in hs.doc and adding __tostring methods to various tables) I'm not sure how much they are really being used at present, though I'd hate to have to replicate them in multiple places -- I do think they deserve a home, but I'm not wedded to their current one.

There is precedent (hs.fs which started as the luafilesystem rock) in adding some of our own additions and changes to a luarock we include with Hammerspoon, so that's a possibility as well.

On Aug 16, 2015, at 11:49 AM, JasonM23 notifications@github.com wrote:

Among other things, it has flatten, compact, difference, union, intersection, zip ... and so on.

My main suggestion though is that you avoid the use of a small homemade library, when there's an extensive higher-order / list processing library well used, supported, and maintained.

—
Reply to this email directly or view it on GitHub #363 (comment).

[lowne]

@jasonm23 yes, i'm aware (as I said above) that moses has a lot more functionality - I was just wondering how you use that additional functionality, if only because there's a good chance that a config using e.g. zip might be interesting enough to contain the idea for a new hs module (or at least an example for the guide/wiki).

[sprig]

Hi!

I have partly read and partly skimmed through this, and I'm not sure whether the original question has been answered; Is there a simple way for me to get luarocks to be recognized by hammerspoon, without messing too much with the rest of my system? I'm asking this from the perspective of a user whose only current interaction with the lua ecosystem is via HS, and I'd hate to start debugging path/loading/duplicate installation issues in this ecosystem I'm unfamiliar with

[sprig]

Ok, since I'm impatient I figured it out - it appears to be unnecessary to install two versions. For reference for future readers:

brew tap homebrew/versions
brew install lua53
luarocks-5.3 install whatever-you-need
## May need to adapt the path here to version updates in homebrew
ln -s /usr/local/Cellar/lua53/5.3.1_1/share/lua/5.3/luarocks .hammerspoon/

After this, adding

require("luarocks.loader")
local pkg = require("the-installed-package")

to ~/.hammerspoon/init.lua
Appears to run without errors.

[asmagill]

To avoid having to link anything at all, you can also add the following at the top of your ~/.hammerspoon/init.lua file:

package.path = "/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.3/?/init.lua;"..package.path
package.cpath = "/usr/local/lib/lua/5.3/?.so;"..package.cpath

Add more paths as appropriate if you use multiple trees with luarocks, but this should give you the idea.

[sprig]

Good to know, thanks!

On 8 September 2015 at 17:22, A-Ron notifications@github.com wrote:

To avoid having to link anything at all, you can also add the following at
the top of your ~/.hammerspoon/init.lua file:

package.path =
"/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.3/?/init.lua;"..package.path
package.cpath = "/usr/local/lib/lua/5.3/?.so;"..package.cpath

Add more paths as appropriate if you use multiple trees with luarocks, but
this should give you the idea.

—
Reply to this email directly or view it on GitHub
#363 (comment)
.

[cmsj]

@asmagill hmm, those paths should already be in package.{,c}path though? They are for me and I don't touch either in my init.lua

[sprig]

You are right actually! I have just tried removing the paths from init.lua and it continues to function with no complaints...

[ecerulm]

As of 2019-03-27

brew install lua # will install lua5.3
brew install luarocks 
luarocks install xxxxx # will install things into /usr/local/share/lua/5.3/luarocks
ln -s /usr/local/share/lua/5.3/luarocks ~/.hammerspoon/

[ddresch]

A little bit off topic but as reference, in case of luasec I needed to add the OPENSSL_DIR which can be defined like this.

luarocks install luasec OPENSSL_DIR=/usr/local/Cellar/openssl/1.0.2p/

But all the rest workes like @ecerulm writes.

[NightMachinery]

I added the paths luarocks path showed:

package.path = package.path .. ';/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;./?.lua;./?/init.lua'
package.cpath = package.cpath .. ';/usr/local/lib/lua/5.3/?.so;/usr/local/lib/lua/5.3/loadall.so;./?.so;/Users/evar/.luarocks/lib/lua/5.3/?.so'

I get this error:

*** ERROR: version mismatch: app. needs 503.0, Lua core provides 504.0
stack traceback:
	[C]: in ?
	[C]: in function 'rawrequire'
	...app/Contents/Resources/extensions/hs/_coresetup/init.lua:651: in function 'require'
	/usr/local/share/lua/5.3/posix/init.lua:23: in main chunk
	[C]: in function 'rawrequire'
	...app/Contents/Resources/extensions/hs/_coresetup/init.lua:651: in function 'require'
	/Users/evar/scripts/lua/pipe.lua:2: in main chunk
	[C]: in function 'rawrequire'
	...app/Contents/Resources/extensions/hs/_coresetup/init.lua:651: in function 'require'
	/Users/evar/.hammerspoon/init.lua:7: in main chunk
	[C]: in function 'xpcall'
	...app/Contents/Resources/extensions/hs/_coresetup/init.lua:702: in function 'hs._coresetup.setup'
	(...tail calls...)

It seems that the packages installed for lua 5.3 don't work with hammerspoon's lua 5.4.

Update: I installed lua 5.4 using these instructions:

LUA_DIR=~/local/lua-5.4.0
# https://github.com/cehoffman/lua-build#installing-as-a-standalone-program-advanced
lua-build 5.4.0 "$LUA_DIR"

lnrp () {
    local f="$1" d="$2"
    ln -s "$(realpath "$f")" "$d"
}
lnrp $LUA_DIR/bin/lua /usr/local/bin/lua5.4
lnrp $LUA_DIR/bin/lua /usr/local/bin/lua-5.4
lnrp $LUA_DIR/bin/luac /usr/local/bin/luac5.4
lnrp $LUA_DIR/bin/luac /usr/local/bin/luac-5.4

LUA_DIR=$LUA_DIR LUA_BINDIR=$LUA_DIR/bin LUA_INCDIR=$LUA_DIR/include luarocks --lua-dir $LUA_DIR --lua-version 5.4 install ...

[kyounger]

For anyone finding this and having issues getting Hammerspoon to work with luarocks from homebrew, here's what I do:

brew install lua@5.3
brew install luarocks
luarocks --lua-dir=/usr/local/opt/lua@5.3 install penlight

No need to augment init.lua.

Trick was figuring out that the luarocks from homebrew does support lua5.3, but you have to direct it to use the lua@5.3 installation when installing rocks. You can have both lua (as of this writing 5.4) & lua@5.3 installed at the same time without issue.

[avi-cenna]

I was using some packages from luarocks (with Lua 5.3) that stopped working after the Hammerspoon upgrade. What I did to fix it is simply:

brew remove luarocks
brew remove lua
brew install lua
brew install luarocks
luarocks install inspect

This removes Lua 5.3 and installs 5.4, which seems to be compatible with the latest Hammerspoon. inspect is a useful Lua package for pretty-printing tables and other objects.

[cmsj]

This removes Lua 5.3 and installs 5.4, which seems to be compatible with the latest Hammerspoon. inspect is a useful Lua package for pretty-printing tables and other objects.

While not relevant to the more general problem of using luarocks with HS, we do have hs.inspect :)