Hey, I'm working on a Gradle plugin that allows packaging Compose applications cross-platform. It's ...

# compose-desktop

[Sebastian Kürten]

Hey, I'm working on a Gradle plugin that allows packaging Compose applications cross-platform. It's called pinpit: https://github.com/mobanisto/pinpit-gradle-plugin

[Sebastian Kürten]

The main focus is on building packages for all operating systems from a Linux build host so that packages can be produced on a very simple build server. In the long run it's probably going to be possible to build on any build system for any target system though. At the current MVP state it's only possible to build from a Linux host and package Debian packages and Windows MSI installers. Packaging from Linux targeting macOS is schedulded to be worked on in Q1 2023.

[Sebastian Kürten]

One major goal is to support cross-platform builds. The other is supporting features that the original Compose plugin does not offer and which are difficult for the Compose plugin authors to implement because even the underlying JPackage does not support it. Instead of trying to get new features into the OpenJDK and eventually into the Compose plugin, this new plugin takes a different approach by not relying on JPackage for packaging. Basically it reimplements whatever JPackage used to do and improves on that.

[Big Chungus]

Looks awesome. Happy to see you're considering Flatpak support. Would be an awesome feature over jpackage

[mikehearn]

Very good! Are you aware of Conveyor? It does all the things you're wanting and a bunch more. In particular it can already do cross-builds e.g. build and sign for Windows/macOS/Linux from any of those combinations. What's your plan for auto update?

[Sebastian Kürten]

yes, we've seen it, however for one of our projects it's crucial for us to rely on open source tools only. If I understand correctly, the part of conveyor that does the actual packaging is not open source right?

[mikehearn]

Right. We do deals to provide the source, if the issue is one of source availability rather than specifically being open source. Good packaging tools are too much effort to develop as a side project, they tend to get abandoned or heavily fragment when open source (electron has this issue). With a business model there is at least a chance of avoiding that outcome.

[mikehearn]

This is for Briar, right? So I guess the issue is one of knowing it's secure/not backdoored.

[Sebastian Kürten]

Yes it's for Briar and indeed security and reassuring our users there are not backdoors are the important points. For Android we provide reproducible builds and this is a goal for desktop releases too. I'm not sure this is possible for all the platforms, but where it's possible we would like to achieve that.

Apart from that I think there is this fundamental question of whether we want to make ourselves dependent on a closed-source commercial tool. I think the arguments are the classical ones in every debate about open source vs. closed source like:
• ability to improve or extend the software without having to rely on the company behind the software
• risk of loosing access to the software should the business model not work out for the company
• etc.
Maybe you're right with packaging tools being too much effort to develop as a side project, but then again on the other hand wouldn't e.g. operating system fall in a similar category? 😉

I know it doesn't always work out that way, but the way I see it, one of the strengths of open source is actually that multiple people from various projects and companies can contribute to the same shared cause and make a task that seems to big for a single individual feasible as a joint effort. I'm not sure what the exact situation is with electron, but it seems that we can partially build on top of some of the building blocks they already established, such as modifying exe properties just as one example: https://github.com/electron/rcedit

[Sebastian Kürten]

What's the business model for Jetbrains and Compose by the way?

[mikehearn]

IDEA and Android, at least if Swing starts to be replaced by Compose. It seems some way off yet. Indirect business models like that are nice if you can get them but often you end up with odd gaps because the primary sponsor doesn't care about any use case except their own. BTW Conveyor can make reproducible packages (modulo signatures, of course). Normally to prove reproducibility you'd write a tool to compare binaries and ignore the irrelevant stuff, like sigs and sig timestamps, then show what changed. Conveyor makes declarative packages also on Windows so there's no problem with backdoors because you can prove that no code outside your own will execute by examining the resulting package (well unless you use the new "aggressive updates" mode but that's optional).

[dewildte]

Where there is money there is usually some form of accountability involved.
The company making the paid for lib not tanking is also a factor to consider.

[Sebastian Kürten]

good point