lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


> 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.

Understood. Thanks for the clarification.

> 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.

As a maintainer myself, I think I fully understand.

> 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)
> :)

No, you're right, it doesn't fully make sense in this context.

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

Heh, it's started happening to me too this month :)

> 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.

Fully understood. This is what I've been saying on my mailing list,
that LuaRocks covers a whole lot more use-cases than the simple ones
that my app's user have. That's actually why there's some debate about
whether using it as a starting-point makes sense for our use-case.
Some people suggest that we should start fresh, given we have
different limitations.

For example, as the author of the app which people are writing modules
for, I'm completely free to say things like "you must use semantic
versioning" and "you must not break backwards compatibility ever" and
stuff like that, with some reasonable expectation that module authors
will follow these guidelines.

That frees up a lot of options that otherwise LuaRocks doesn't have,
at least when installing modules for my app. So I can't help but
wonder if it's still possible to go down that route and take advantage
of those possibilities, while still using LuaRocks.

> 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.

I'm definitely open to some kind of collaboration.

-Steven