Hi, I have an idea for an open source project I want to build: a tool to assist mob/pair programming, part of which would be keeping the local dev files in sync during a session, among other things. Has anyone used syncthing as a module? Looking at the source, it looks like there is no “internal” package, so this should be theoretically possible.
I tried a few years ago but failed. I wanted to make my basic C-bindings for Syncthing Tray depend on Syncthing built as Go module. It was almost working. However, the assets were missing and I could not figure out how to tell the Go build system to invoke the required build command when building Syncthing as a module (so I ended up doing that part via CMake and adding the mentioned change just to Syncthing itself in form of the mentioned patch).
I am not the most experienced Go programmer and maybe the Go build system has improved since then. So if you find a way to overcome this problem I’d be curious to learn about it.
(By the way, another problem I could not solve is telling the Go build system to emit e.g. a pkg-config file to avoid having to guess required libraries of the static library it emits. However, you might not need that if you stay within the Go programming language or make it emit a dynamic library.)
Well, my plan here is to build the whole thing in go which should make this a lot easier. I should be able to use the source code as modules directly because none are marked as internal.
That’s mostly incidental. Syncthing is an end-user application, not a library. At least primarely. You should consider everything as internal. As in we may be breaking exported package APIs at any time, without any respective semver bumps.
Also what @Martchus describes is true because we use our build script to generate assets during the build. Whether or not that affects your use case depends on what you are doing/using of course.
That’s also what I did. I wanted to do as much within the Go build system as possible. I only resorted to building the assets separately (via an additional command invoked by CMake) because the Go build system didn’t seem to allow me executing additional commands during the build of Syncthing as a Go module. (That I also embed everything in the end into a CMake build script anyway does not matter for this consideration as this already failed on Go-build-system-level.)
Of course the point of @imsodin about breakage is even more important. If you go down this road, be prepared to having to adapt your code from time to time. (I didn’t find it very problematic in my case, though.)
By the way, the easiest way to find out limitations and what works and what doesn’t is to just go ahead and try.
1 Like
I’ve just read Beta test my new iOS app for Syncthing and it looks like this app is in fact using parts of Syncthing as Go module, see e.g. sushitrain/SushitrainCore/go.mod at main · pixelspark/sushitrain · GitHub.