Forking a library and potential maintainer list

[mkpankov]

Hello @tomaka and everyone else,

The following is not to bash the author and previous contributors, just statements of facts.

At this point it's pretty clear library is unmaintained, and issues and PRs just pile up.

No major PR was accepted for half a year at least, with several having no comments and otherwise being stale.

I propose forking a library to an organization, and establishing a small team of currently active library users.

We'd then take care of current unattended PRs and at least triage the issues.

In case there are any objections, please let us know.

Tagging people who might be interested in maintaining, based on previous contributions:

• @mkpankov
• @tpdickso
• @giodamelio
• @kpcyrd
• @linkmauve
• @sunshowers
• @jonas-schievink
• @Ameliorate
• @TyOverby

Let's discuss the path forward.

[tomaka]

I can transfer the repo to an organization if you want, but to be honest the big reasons why nothing has advanced is that:

• I dislike the AnyValue and AnyLuaValue types that I consider as hacks that would eventually be removed.
• One and a half years ago I stopped working on the library because of issues with the Rust language not allowing me to do what I want, and I know that these issues are still not fixed.
• It would take more time to discuss issues than actually do changes myself.

[tomaka]

My point is that people seem to push the library in a direction that was not the same as me.
However considering that it is unmaintained anyway, I don't see a reason to prevent that from happening.

[jonas-schievink]

Nowadays I usually point people towards rlua instead, which is actively maintained and has more features. Maybe deprecating hlua in favor of that would be an option? Given how hard it is to write safe Lua bindings I think concentrating the efforts in a single library might make more sense.

[mkpankov]

I'll repost my comment from another issue (#201 (comment))

The projects have wildly different goals, advantages and drawbacks.

This project certainly shouldn't be deprecated just because rlua exists.

When I checked rlua last time (about a year ago), it was registry-based only and had significant limitations on what could be pushed to Lua. Additionally, there were issues around passing stuff to other threads.

So I'm mainly interested in further development of stack-based approach.

[mkpankov]

I dislike the AnyValue and AnyLuaValue types that I consider as hacks that would eventually be removed.

What is blocking the better approach?

One and a half years ago I stopped working on the library because of issues with the Rust language not allowing me to do what I want, and I know that these issues are still not fixed.

Are there issues besides rust-lang/rust#38673?

It would take more time to discuss issues than actually do changes myself.

Okay, but that requires you to be involved, which doesn't seem to be the case?

My point is that people seem to push the library in a direction that was not the same as me.
However considering that it is unmaintained anyway, I don't see a reason to prevent that from happening.

I'm not into forking for the sake of forking, I'm just interested in accepting features that are already implemented and improved (read: current PRs) and fixing bugs that at least aren't blocked by the compiler (mostly crashes and other UB caused by improper FFI or segfaults in Lua).

That said, if no one else is interested, I'm not sure I'm able to pull the weight.

[tomaka]

Are there issues besides rust-lang/rust#38673?

Higher ranked lifetimes, while not strictly necessary, would greeeeeeaaaaatly simplify the code.

I'm not into forking for the sake of forking, I'm just interested in accepting features that are already implemented and improved (read: current PRs) and fixing bugs that at least aren't blocked by the compiler (mostly crashes and other UB caused by improper FFI or segfaults in Lua).

Maybe I'm giving the wrong impression, but I'm not opposed to forking or getting more help!

[mkpankov]

@jonas-schievink found the issue that blocked using rlua in my projects, decided to post it here mlua-rs/rlua#40

May be worth reconsidering now.

[surajprak]

@tomaka please continue with your good work. I worked with it extensively and find it elegant. @mkpankov i agree that rlua is not a reason to shutdown hlua.