Batis - XDG-based packaging for Linux desktop apps

[Thomas Kluyver]

Hi Matthias,

Thanks for your thoughtful reply.

On Sat, Nov 21, 2015, at 09:02 PM, Matthias Klumpp wrote:
> I suppose you have looked at existing solutions to the problem, like
> 0install, Limba and XdgApp. What is the thing which makes your project
> special compared to those (there must be some unique selling point,
> right?)?

I have looked at them. The main unique selling point of Batis is that
the packages are regular tarballs with a self-contained install script,
so they're usable even if users don't have Batis installed. I'm trying
to avoid the catch 22 where developers don't use a new distribution
system because it has no users, and users don't use it because apps
don't refer to it.

Simplicity is a secondary point. Batis is designed as a step up from
what many cross-platform developers already do for Linux - manually
creating tarballs - rather than a big rethink of software distribution.
This also means that it's simple to add Batis metadata to plain tarballs
that are already available; I've created scripts to do this for a few
applications here:
https://github.com/batis-installer/batis-adapt

> I didn't look a Batis very closely yet, but I have a few questions:
> 
>  * It looks like Batis allows apps to depend on distributor-provided
> software - how do you handle missing dependencies of your software?
> How do you plan to handle binary incompatibilities?

Apps can specify dependencies on Linux distro packages. If there's a
specification matching the distro you're running at install time, it
will try to invoke the system package manager to install the required
packages. If not, it will ask the user to ensure the necessary
dependencies are installed manually.

This is admittedly the crudest part of Batis. The idea is to automate,
where possible, what would otherwise be human readable instructions like
"MyApp relies on Python 3 and PyQt5. If you're on Debian/Ubuntu, run
'apt-get install python3-pyqt5'. For Fedora, run ...".

I would be interested in extending this to use AppStream metadata, but
that's another thing for application developers to learn about... and
another thing for me to learn about. Also, I'm not sure how many
packages provide appstream metadata; on my computer, there are not a lot
of files in /usr/share/appdata/.

>  * Batis allows scripts to be run at install time - how do you want to
> secure your installation processes, and adapt the newly installed apps
> to the system they are running on? IMHO and automatic configuration or
> a declarative interface would be much better than to allow the
> execution of arbitrary scripts at install-time.

The script is only a fallback option for users who don't have Batis
installed. The real interface is completely declarative: a couple of
JSON files, and a selection of icons, .desktop and mime XML files at
predictable locations. When you 'batis install ...' or click a batis://
link, no code from inside the package runs to install it.

The install.sh script inside the packages actually uses a copy of the
Batis code included in every package, and simply tells it to install the
directory containing install.sh. This assumes that desktop Linux systems
will have Python installed, which seems reasonable for the foreseeable
future. The code this uses is compatible with Python 3 or 2 (other parts
of Batis require Python 3).

Thanks,
Thomas