Best way to integrate xplr into another project

[orhun]

Hey!

I'd like to integrate xplr to gpg-tui for file selection. By integration I mean using it just for selecting a file. See gpg-tui#2.

First option is to run xplr command and read it's output from stdout after the file is selected. This is quite easy to do except that it will require the installation of xplr, obviously.

Second option is using the library to run xplr TUI. I'm not sure how easy that'd be so that's why I'm asking here.

Which one do you think is better? What are the downsides? Do you have any other suggestions/ideas?

Thanks in advance.

[sayanarijit]

I'd first go with the command option and see if there's any limitation. I haven't checked but cargo should have an option for adding external crate bin as dependency. If not, another option would be to add a simple plugin interface that can auto install binaries, and can be reused to support other non-rust binaries too. For e.g. fzf.

If you prefer tooling to be tightly integrated, xplr can be used as a library but I would like to add some final polish to the API first. You then can't use fzf and have to go with options like skim which also provides a library API, which you can use right away. So if you want to go this path, try integrating skim and let me know. I'll then polish the xplr lib and make it ready for integration.

[sayanarijit]

Actually, you don't need to try integrating skim, just let me know if you prefer tight integration. I think I can make the api as simple as result = xplr::run(). You need to temporarily pause your input readers and tui, run xplr, then resume your input readers and tui.

[sayanarijit]

But ofcourse, the simplest way would be to use loose integration and depend on the users to install appropriate binaries. If properly documented, I don't think users will have any trouble installing the required binaries

[orhun]

Yes it seems like it's better to go with the first option for now. A few things that I considered are:

• It can use the system-wide configuration (if any) when running the binary. Otherwise I should be handling that when I use the library.
• I don't have to compile extra dependencies if I just run xplr command, it's a little thing but it's important for the binary size.
• I think it's better to leave the choice of "which version of xplr to use" to the user.
• In the meantime, you can finalize the API for people like me who want to integrate xplr. I can switch to this solution in the future.

Thank you!