Using libpijul from C?

Hey there,

As a little side-project, I’m looking to implement a minimal GUI for pijul. As far as I can tell, pijul’s CLI client is nicely separated from pijul’s back-end, which is provided by libpijul. My question is, is there a way to access libpijul’s functions from C as-is, or would I need to fork it and expose functions myself?

I don’t yet know Rust, and learning it is outside of my purview in this case, hence why I’m trying to do this in C. As far as I can tell, this article describes how a function might be exposed, and that pattern isn’t present in libpijul as far as I can see, but I am not knowledgeable enough about the codebase to know for sure.

I think it’s better to parse the output.
Some subcommands have flags for JSON output.

However, note that this project is abandoned, so don’t put in too much effort.
Also, note that unfortunately there is zero support from the maintainers for ecosystem development (GUIs or any other tooling), so you are pretty much on your own.

This project is far from being abandoned. Some people (you?) may have abandoned it, but its main authors and contributors haven’t. As far as I’m concerned, I use Pijul every day in my work and I’m working on some really ambitious features which take more time to implement than some users seem to expect (you can’t release an important breakthrough every day: such “breakthroughs” are called “trivial features”).

2 Likes

Is an appimage file a major breakthrough?

Well, this got off-topic disappointingly fast.

Despite it being a workable solution, I’d prefer to avoid having to parse output.

Indeed, sorry about that. Back to your original question, I’d love to have a C API, which isn’t possible “as is” from Rust, since many things need to be “boxed” or “unboxed” to provide stable pointers.

I’m quite interested in helping you achieve this goal. I believe a good way to start would be if you gave me a “shopping” list of the calls you’d like, ranked from “most urgent” to “nice to have”. Some will be obviously be harder to implement, like the ones using standard Rust APIs (iterators, for example, like pijul log), but still much simpler than parsing C.

Also, I’d like to take the opportunity to explore calling these functions from Python using PyO3, so we could definitely do that.

Also, I’ve been invited to create an assembly at 38c3, so if anyone wants to meet in Hamburg at the end of December I may go there if I can get a ticket.

Apologies for the late reply; between break and final’s week, things have been somewhat busy!

I suspect that there are a number of pijul functionalities that would be easier to outright implement myself rather than exposing them. Unfortunately, I am not familiar with the project on a mechanistic level, so I don’t know what those functionalities might be. With that said, my wishlist is ranked primarily by the functionalities of pijul that I personally use the most.

High use:
record
unrecord
diff
init
change
log
add
remove

Sometimes use:
clone
push
pull
channel
fork

I have rarely if ever used the other subcommands, but I’ll admit that I mostly use pijul for small, non-collaborative projects, so my list will clearly be skewed.

In the mean time, I’ll do some reading up on pijul’s code and see whether there’s anything that can just be re-implemented outright to save some work. I probably wouldn’t trust myself with the creation of patches, for example, but it may be the case that things like the log are easy enough to skip.

(off topic - should be moved to another thread)

Why is an AppImage needed? It’s only useful for large apps, e.g. GTK or Qt, that load many shared libraries, icons, and other assets. AppImage creates a single binary from these. Pijul can be compiled into one static binary, so there is no need to create an AppImage file just to hold a single binary. Use a musl-based system (or a Docker container based on these) for compilation, e.g. Void, Chimera, or Alpine, because glibc doesn’t support static linking.