Straightforward Library for Custom Platforms - #4107

I'm glad somebody is working on this, I tried to do it a while back but came across too many roadblocks and decided to give up and go an alternative route.

IMO, dependencies should be handled with the build system of the project that will use the library. IE the library should expose them as transitive dependencies, the dependency loading system of luckperms is great for normal servers but are not needed in this case.

One other problem is maven publishing, there is no form of automated publishing right now, although I am sure it can be solved if @lucko would be willing to adopt this PR.

I am undecided whether this is something the project should support long term - I think if we did, I'd prefer a refactor of the existing standalone module to support instantiation from within other projects instead of a new library module. If I have understood correct, I think you have suggested this too in the comment above.

Out of interest - did you consider using the existing LP standalone component with the REST API? https://github.com/LuckPerms/rest-api There is also a java client - https://github.com/LuckPerms/rest-api-java-client

I think that is how I would architect a solution to achieve the same goal. Run LP standalone as its own component, then interact with it using the REST API.

In more traditional systems, it's pretty standard that you would run something like Active Directory or LDAP to handle user/group management, then interact with it from other systems via APIs, not try to embed LDAP into your app.

Alternatively.. have you considered actually just using LDAP, or Keycloak or FreeIPA or similar? :P

The main difference between what I was suggesting doing and just refactoring the standalone module is that what I was suggesting involves adding a module which would allow you to download only the relevant code without anything specific for the standalone tool (such as the docker and terminal stuff). Otherwise, the actual amount of code would be basically equivalent. Is there any specific reason you would want to avoid adding a new module (even though the total amount of code in the repo is very similar)?

I hadn't considered using the REST API and standalone tool together, but this seems like a decent solution. However, this wouldn't have allowed for the changes I was considering for the storage format (which I would still like to add). If I'm reading the documentation correctly, it also looks like the REST API doesn't support executing commands in the same way; the /action has the target separated out rather than embedded into the command (I can't just say "execute from the perspective of <user>: /lp user <username> permission set <permission> <value>"; it wants "execute from the perspective of <user> modifying <username>: permission set <permission> <value>" which requires extra parsing before sending the command).

Using the REST API like that also feels a bit convoluted; why have the program (1) unpack standalone LuckPerms from my program's resources, (2) start up a separate process, (3) then interact with that process through a REST API, and finally (4) make sure the LuckPerm files get properly cleaned up on program exit, when it can just execute the code directly like how Minecraft servers do?

The biggest reason to use LuckPerms over something like LDAP is familiarity, both for the users of my program and myself. It is also already designed for almost my exact use case, only, instead of a "Minecraft server," it's a "Minecraft-related server that still involves users logging in with their Minecraft accounts."

Note that my program is meant to be ran by anyone, not just ran on my system, which is why it should be self-contained and easy to setup.

However, this wouldn't have allowed for the changes I was considering for the storage format

im pretty sure you can make an extension that adds a custom storage method already, and it would work on all platforms

The StorageImplementation (which is from CustomStorageProvider) appears to only cover the database itself, not any of the other files (config, contexts, editor-keystore, libs/, translations/) - so it is not currently possible to combine everything into one file (and in particular the same file/database I would be using for my own program's data storage)

It looks like 6 of the tests in the standalone module fail. Are the tests actually needed, or can I delete them to simplify the major refactor to make it depend on the library module?

EDIT: This question is still relevant, the following commit just ignores the tests for now

I am now revisiting this pull request and my requirements have changed slightly, so I no longer need the ability to store everything within a single file. This greatly simplifies things, and was the main part that I had not yet completed. I believe the changes I have already made are similar to what I now need, and would like to finish up this pull request if possible. Now that I have been able to test this system in conjunction with my use case, I can confirm that this pull request is extremely useful for projects like mine.

@lucko
Therefore, I would like to check if this is something you think I should clean up and get merged, or if you have decided that supporting this is not a good idea and the pull request should simply be closed.

Note that I do not plan to maintain this personally, so if this does not get merged, I will simply archive the fork in case someone else wants to look at it. I have some alternatives that mean I do not need this for my project, but the alternatives are significantly worse than using LuckPerms in my opinion.