Need a luarocks upgrade command to upgrade installed rocks

[agladysh]

No description provided.

[petsagouris]

This is a must, but my head spins...

How would LR handle bad results, conflicts, bad rocks...?

Since we are talking batch rock actions, would there be any sense in an option to purge all rocks from the system ?

[agladysh]

1. Banish the misfeature with multiple installed versions of the same rock.
2. A. If when upgrading user did not said --only-from: Check all available rock repositories for each installed rock.
3. B. Otherwise: Check only specified repositoryfor each installed rock.
4. Determine maximum found version.
5. When all rocks are checked, filter out not updated rocks.
6. Add necessary dependencies.
7. Uninstall old versions for everything in the list. Install new versions, calling necessary hooks.
8. If there are some rocks that were not manually installed (but brought as dependencies), and they are dependencies no longer, suggest user to autoremove them.

Purge all command rocks makes sense — I need it rather often. Please create a separate ticket.

[felipedaragon]

This would be similar to "apt-get upgrade", right? I think it would be a cool addition.

[tiye]

+1 , trully need this one.

[hishamhm]

For future reference:

This commit introduces the luarocks list --outdated command, which does what you expect:

e5cd7a9

And here we have a discussion about the difficulties around an upgrade command:

http://article.gmane.org/gmane.comp.lang.lua.general/112719

Also, the luarocks purge is also available by now.

[felipedaragon]

cool! I still have to get more familiar with all the LR aspects.

[Asmageddon]

Regarding that discussion, I imagine that dependencies could simply be installed differently from packages the user requests and be allowed to be installed in multiple versions, perhaps somehow linked to individual packages that need them, if that's even possible.

[mpeterv]

@hishamhm I think it would be great to decide on upgrade functionality interface and possibly on changing default install behavior for Luarocks 3.

[Abhinand-p]

@catwell There should be a mechanism to embed old rock into new at least logically. Some transformation parameter check to be performed. If developer go on building new rock without parameter normalization required for semantic level, then we cannot provide up-gradation. Dependency chains can be logged in a data file. More linking types are investigated for old to new, less work will be for user.

[Abhinand-p]

@catwell
A command to upgrade shall have the operation tree like:
1> Make dependency data file. (Automatic look up table of different functionalities)
2> Upload dependency data file. (Directories setting)
3> Partial build of virtual rock. (Query on server, buffer, retaining old and new versions in a amicable format)
4> Upgrade interface (GUI also required)
5> Upgrade command (Repository path)

[a1shadows]

http://article.gmane.org/gmane.comp.lang.lua.general/112719

This link doesn't seem to be working. Also, is there any work ongoing on the upgrade command? Thanks.

[catwell]

Here is a copy of the link in the Internet Archive.

Full text of @hishamhm's post:

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.

[a1shadows]

Thanks!