[Sputnik-list] Versium, which repo?

[Yuri Takhteyev]

Sputnik can be installed in a bunch of different ways, and my plan is
to expand those options, not to contract them.  Right now you can
install it with its own Kepler or have it be just one of many Lua
scripts on a Kepler installation.  You can install it with or without
LuaRocks (if that's not the case with the latest version, that's an
oversight which I will correct).  I want to soon make it usable with
or without CGILua.  When I work on it, I keep all of those scenarios
in mind, but I haven't had the time to document all of them, not to
mention providing install scripts.

So, before we get into install scripts, here are the scenarios that to
I want to be able to support:

1. Use Kepler 1.1 installer, use CGILua, capture all CGILua traffic
and send it to Spunik
2. Use Kepler 1.1 installer, use CGILua, let CGILua do dispatching the
normal way
3. Use Kepler 1.1 installer, use Sputnik directly on top of WSAPI
4. Install WSAPI (as a Rock or manually), run Sputnik on top of it,
don't even bother installing CGILua, etc.
5. Install Sputnik on top of whatever other server that works with
Lua, e.g. HTTPLua.

All of those options could be supported with or without LuaRocks,
though without Rocks there would need to be an alternative system to
make sure that all the necessary packages are installed.  I don't want
to create an alternative installation system for Lua, since I think
LuaRocks is doing a great job.  However, it perhaps would make sense
to see Debian package system as an alternative to LuaRocks.  I.e.,
much like Sputnik "rock" has a dependency on several versium,
luafilesystem, markdown, etc. rocks, it might make sense that sputnik
package for debian would depend on a debian package for versium, lua
markdown, lfs, etc.  I am saying "might" simply because I am not an
expert on debian packaging system and I really don't know what would
and would not make sense there.  Just an idea.

The same would theoretically apply to plugins: it should be possible
to install a plugin manually (with some work, that is), to install it
with just something like "luarocks install sputnik-tickets" for a
LuaRocks based installation or, potentially, package a plugin as a
debian package.  The serious question is the following: if debian
package is installed without Rocks but most plugins are not available
as debian packages, people who install Sputnik as a debian package
will be out of luck when it
comes to plugins.  (Or, rather, they will be able to install them
manually, but that would be more work.)

Now let me tackle specific questions:

> OK, now it is clear I was toying with the wrong version. I still don't
> understand why you need to commit the sources of Versium into sputnik
> repository to hack on them...

At the moment I am working on it by myself and it's just easier to do
a single commit into one repository than to deal with two.  Once it
stabilizes, I will move Versium to its own respository.

> I think LuaRocks can be part of Debian, but I don't think it is a top
> priority task, thus my last efforts were to package lpeg, leg and shake..

Sure.  I think the relationship between Rocks and the debian package
system is a good topic to bring up on the luarocks list.   Other than
that, I don't really an opinion about how it should work.  Note
though, that "Kepler 1.1" is at it's base an install script.  In other
words, the Kepler team has written a set of Lua packages, and "Kepler
1.1" is a script that installs a certain set of those packages in a
way that makes them work together.  From this point of view, the
debian package system would also be somewhat of an alternative to the
Kepler 1.1. installer, right?  So, what is the relation then between
the debian package system and "Kepler 1.1"

> So please, don't make your software unusable without LuaRocks.
> While I was toying with sputnik, I just had to remove a require
> "luarocks.require" line to make your software load packages from
> standard locations. That sounds good for me, and in case a version of
> sputnik is packaged for Debian I'll be careful to make all dependencies
> satisfied with the right versions.

I believe 'require"luarocks.require"' only shows up in installer.lua
and in cgilua/config.lua.  You can safely comment it out in both.
Again, if the debian package system can satisfy all the dependencies,
it should all work fine without rocks.

> Just an item in my wish list: In a system wide installation of sputnik,
> where at least the core modules (like sputnik, cgilua, versium, wsapi,
> luafilesystem...) are available system wide, is pretty silly to
> install the whole Kepler for every wiki that may be run by the computer
> (imagine a web server with some virtual hosts on it, or just many ~user/).
> I'd really like to have a less intrusive installation script, to just
> initialize a directory with the data/ directory and the configuration
> files needed by sputnik, like the one doing wsapi.cgi.run(...).
>
> I can collaborate on that script, if you agree it is a nice thing to have.

Perhaps, but let's talk about it a bit first.

First, it's quite easy to do that now, even though there isn't a
script for that:

1. Install Kepler system-wide
2. Keep cgilua/config.lua as is
3. Put cgilua_sputnik.lua into htdocs (as currently)
4. Use sputnik.cgi/cgilua_sputnik.lua as your BASE_URL

However, I think Sputnik's dependency on CGILua is quite unnecessary
now that WSAPI is out and is included with Kepler by default.  So,
instead, I want to port Sputnik to WSAPI, which really just means
writing an alternative to cgilua_sputnik.lua.  In other words,
cgilua_sputnik.lua is a 40-line adapter between Sputnik and cgilua.
Now I want to write an adapter for WSAPI.  With this adapter, it would
be possible to launch Sputnik by just using a simple cgi script that
would look as:

    #!/home/yuri/tmp/sputnik/bin/lua5.1
    KEPLER_DIR = "/home/yuri/tmp/sputnik/"
    local libext = "so"
    package.path =
KEPLER_DIR.."/share/lua/5.1/?.lua;"..KEPLER_DIR.."/share/lua/5.1/?/init.lua;"..package.path
    package.cpath = KEPLER_DIR.."/lib/lua/5.1/?."..libext..";"..package.cpath
    -- require "luarocks.require"
    local cgi = require"wsapi.cgi"
    require" sputnik.web.wsapi"
    cgi.run(sputnik.web.wsapi)

Note that in this case it wouldn't matter if you install Kepler
locally or system wide and if you use Kepler for something else.
You'll just need to make sure that the first two lines set the right
paths.   And you'll also have to make sure that you have all the
dependencies: a few Kepler pacakges (luafilesystem, md5, logging),
markdown, and a few of my packages that I was thinking of distributing
separately from Sputnik (versium, cosmo, colors).  (The latter
packages can of course be also distributed together).  It's up to the
user how to satisfy the dependencies.  LuaRocks is a nice option.
Using the package manager for debian or another distro would be
another nice option.  What i don't want to do is to write an install
system that would be a poor-man's version of LuaRocks.  Note that with
all this WSAPI-based approach, there will be no "installation" other
than satisfying the dependencies and generating the 9-line cgi file
that has the right paths in the first two lines.

Does this make sense?  If not, let's talk about it more.  I really
appreciate your offer to help and I hear your concerns.   Let's just
make sure we don't end up re-implementing luarocks.

- yuri