Re: Lua Distributions and Package Management

[Sean Conner <sean@...>]

It was thus said that the Great steve donovan once stated:
> On Thu, Sep 26, 2013 at 6:18 PM, Sean Conner <sean@conman.org> wrote:
> >   Coming from the Unix world, I'm used to the "configure; make; make
> > install" method of installation [1].  And unless I change it with some
> > options to configure, everything ends up installed in /usr/local.
> 
> As a practical contribution to this otherwise entertaining discussion,
> I've put together a generic installer script here:
> 
> https://gist.github.com/stevedonovan/6742163
> 
> The basic idea is that you customize the script and put a little
> install function up front. For instance, LDoc is easy, since it's just
> a matter of creating a wrapper which points to ldoc.lua in the dir you
> extracted the archive:

  "You" as in the person trying to install a package, or "You" as in the
author of a package?  Because the way you wrote that, it sounds like "You"
as in the person trying to install a package.

> Currently this script is sitting uneasily between 'dead simple' and
> 'covers everything'; I have had to make assumptions. On Unix, if you
> run as su, scripts go to /usr/local/bin and modules go to the usual
> places. If not su, it will try to find a directory on the Lua module
> path which is user-writeable, and ditto for /home/user/bin for
> scripts.

  Careful there, as a default Unix install of Lua has "./?.so" first in the
LUA_CPATH and "./?.lua" in the LUA_PATH, so if you aren't root, then you're
going to be trying to install in the current directory, which may not end
well.

 Some other comments going over the code:

  1. To be pedantically correct (and who doesn't 8-P you should use
package.config, as that contains:

	LUA_DIRSEP    = package.config:sub(1,1)
	LUA_PATHSEP   = package.config:sub(3,3)
	LUA_PATH_MARK = package.config:sub(5,5)
	LUA_EXECDIR   = package.config:sub(7,7)
	LUA_IGMARK    = package.config:sub(9,9)

  From that, you should be able to determine the shared object extension by
looking for LUA_PATH_MARK .. ".(%S+)" somewhere along package.cpath.  

  2. I was unaware that $HOME/bin was a common Unix idiom.  And why are you
checking for $HOME/bin (or /usr/local/bin)?  

  3. I have an issue with your Windows version of an absolute path.  On
Unix, '/' as the start marks an absolute path, but that's only because Unix
does not have the concept of drive letters.  On Windows though, you have

	path/... [1]

which is a relative path to the current location.  Then you have

	//...

which is an abolute path on the current drive, and then

	C://

which is an absolute path on a particular drive. Also, Windows isn't the
only operating system with the concept of "drives"---there's AmigaOS, which
had the concept, but didn't limit it to a single character:

	DF0:System

Heck, that leads me to ask (since I don't have a Windows system to test this
on)---is

	C:path

valid?  That is, relative to the current directory on the C: drive?  I seem
to recall that MS-DOS kept track of the current directory on each drive.

  4. 

	[spc]lucy:/tmp/foo>lua install.lua 
	mkdir -p /home/spc/.luarocks/lib/lua/5.1/
	cp -r  lua/mod /home/spc/.luarocks/lib/lua/5.1/
	cp: cannot stat `Lua/mod': No such file or directory
	install: command failed: were you running as an administrator?
	[spc]lucy:/tmp/foo>

  -spc (Just saying ... )

[1]	Yes, that *IS* a valid path in Windows.  The Windows kernel does not
	care if you use '/' or '\' as a path separator and will happily
	accept both.  It's just the default Windows command line that
	bitches, and only because Windows (and MS-DOS, the precursor to
	Windows) used '/' to mark command line options [2][3].

[2]	Which came from CP/M, which in turn, got it from RT-11.  Past that,
	I don't know where it came from.

[3]	INT 21H, function 37H, Get/Set Switch Character

	Entry:
		AH - 37H
		AL - 0 	read switch character
		AL - 1	set switch character (in DL)
		DL - character
	Exit:
		DL - switch character
		AL - 0FFH on error

	It defaulted to '/' but could be changed.