Re: Lua package manager(s)

[Hisham <h@...>]

On 8 September 2014 15:14, Steven Degutis <sbdegutis@gmail.com> wrote:
> I recently wrote a Mac OS X app[1] that just acts as a Lua host, and I
> wrote some packages for it that let you do things like inspect and
> move windows, bind global hotkeys to arbitrary Lua functions, etc...
> It was called Hydra but the name had to be changed to Mjolnir for
> trademark reasons.
>
> Anyway, there was a lot of disagreement among my app's users for how
> to install packages. So I took out the internal package management
> code I wrote, moved all my modules to LuaRocks, and told all my app's
> users to just use that for their packages.
>
> But there's been a lot of discussion on my app's mailing list about
> wanting a different package manager. Partly because LuaRocks (1) is
> missing some features like being able to know what packages can be
> upgraded, and being able to upgrade them, and (2) is designed for the
> command-line primarily, and we're not sure it's reasonable to embed it
> into my application and use it in a Lua-prompt (i.e. REPL).
>
> As for #1, there has already been an open issue about this for
> years[2] which has not seen any activity, and I've posted a new
> issue[3] requesting this feature, which also has not seen any
> response. So this gives me no hope that this feature will be added any
> time soon, or that a pull-request including it is welcome.

A pull request is welcome. I have mixed feelings about feature
requests in the bugtracker (and the fact that Github calls it all
"issues"), because these are not really bugs or issues, they're
wishlist items.

People have at times requested different things: a command to list
what packages have more recent versions, and a command that
auto-upgrades everything. The latter I think is very questionable. The
former is less dangerous, but who says that a newer version of a
package is compatible with the previous ones?

Scanning the repository and telling you what rocks have a version with
the same name and a different number is easy. Cross-referencing all
your existing installed rocks with those versions and figuring out if
any dependency chains break if the older rock is replaced by the new
one is much harder.

Add to that the possibility that two available upgrades may be
mutually incompatible: say you have A 1.0, B 1.0 and X 1.0; A 2.0 is
available, but it requires X <= 1.0; B 2.0 is available but it
requires X >= 2.0. What to do? In LuaRocks we can keep them all
installed at the same time if you use luarocks.loader, but users have
complained about our feature of keeping versions simultaneously, so
that's not the default anymore. Users who ask for auto-upgrade want
the old versions to be removed.

(And no, "enforce semver to all rock authors!" is not possible.)

So, (1) it's not trivial to get the upgrade feature 100% right, (2)
whet it is not 100% it has great systeam-breaking potential, (3) it
may be impossible to make everyone happy since people want different
things.

Sorry about the pessimistic description, but that's one of those
"obvious features" that everyone wants but that's much harder to do
than it seems. Having said that, a simple list-available-upgrades
command wouldn't be that hard. Obviously, once that's in, people will
instantly ask "why can't I give it a command to install all these at
once?"

So that's why _I_ don't have plans to implement "luarocks upgrade" in
sight. If you'd like to implement it (or at least "list-upgrades") and
send a pull request our way, please document all design decisions so
we can point users in the direction of the documentation when they ask
for auto-upgrade (or ask why upgrade doesn't work the way they want)
:)

(Looks like it's unavoidable that long-time maintainers start sounding
grumpy... I hate to see it happening to myself!)

What I want you to take from this is: it's not due to simple lack of
goodwill that we lack an "upgrade" command. But we want to make
LuaRocks useful for many use cases including yours, and I hope we can
collaborate towards that. The goal for the next releases is to make it
more extensible and more embeddable. It would be awesome if we could
have your help to make that happen, and making sure LuaRocks serves
your needs; it would certainly be less work for everyone involved.

-- Hisham