Some distributions (e.g. Arch Linux) have decided to make the "python" command run Python 3 by default. This is a problem for us, because Python 3 is not compatible with Python 2. Most Python ROX applications start like this (e.g. Edit/AppRun):
On Arch Linux, these programs will now fail to start. We can't change the line to run "python2", because that doesn't exist on other systems (e.g. Debian).
To solve this, I've added a 0install feed for Python. If your feed currently looks like this:
E is a "secure distributed pure-object platform and p2p scripting language". I've been writing programs in E for a little over a year now. Here's a quick summary of the cool features I've found so far in this surprisingly overlooked little language.
Normally, a ROX AppDir is a read-only directory containing program code. This makes it easy to manage programs using the filer. However, it's hard to manage configuration, which goes in various hidden files (hopefully under ~/.config).
With 0install, the program's code goes in a shared cache instead, allowing it to be shared automatically, and leaving the application directory almost empty.
This opens up the possibility of reusing the appdir for configuration. Instead of making it easy to manage code with the filer, this makes it easy to manage configurations.
In 2007, OSNews ran an article about OPIUM, showing how to cast apt-get installation problems (choosing which of several possible dependencies to install) as a set of pseudo-boolean constraints which could then be solved mathematically to give the optimal solution. I this post, I'll describe how we've recently adapted this technique to Zero Install, addressing some problems experienced by the Sugar environment (One Laptop Per Child) and allowing better integration with distribution packages.
There was some discussion on the mailing list about which programs are still actively maintained. Here's a diagram showing all the programs we include in the no-network bundle and their release dates (from their Zero Install feeds). Releases without dates aren't shown (these are generally very old releases).
I've been busy recently making loads of improvements for dealing with binary releases and compilation:
0compile is now much easier to use.
First, there's the new autocompile feature, where it takes the URL of a program and downloads and builds it, along with any required libraries. This should make it easier to compile and run programs like ROX-Filer on systems where up-to-date binaries aren't available.
Secondly, 0compile is easier to use when compiling local source code (e.g. a GIT checkout) - you don't have to do the build in a separate directory and it takes the version information from the feed in the checkout, instead of taking a copy.
Finally, it's better at tracking new versions of dependencies; if a new version is available then it will prompt you to do a clean build (or revert to the older version).
0release is a huge time-saver for making releases. Given the path to the local feed in a GIT checkout it can manage the whole release process for you: creating the release candidate, running the unit-tests, diffing against the previous version, signing the release with your GPG key, uploading to your server, testing the upload and updating the Zero Install feed. All you have to do is confirm the new version number and enter your pass-phrase.
It's always been useful for releasing Python code, but for C programs it previously only published source code. Now, it can build binaries (possibly using remote or virtual machines to build for multiple platforms) and publish them too, automatically, for any program that can be built using 0compile.
0test provides an easy way to run your program's unit-tests with any dependencies, but the clever bit is that you can test combinations of versions. For example, you can test a new release against the last five releases of ROX-Lib with one command.
I've also patched ROX-CLib to use 0compile to compile. This has a number of advantages:
Experimental, but if you have a cluster of machines and don't want to have to download the same packages for each one, the new peer-to-peer sharing system allows a machine to discover that a nearby machine has the program it wants and copy it across directly!
Ever wondered what D would be like if its syntax was inspired by Python instead of C? I had to find out, and the result is Delight.
I find the code easier to read without all the extra braces and parenthesis. Delight inherits all the D goodness: classes, interfaces, templates, exceptions, dynamic bounds-checked arrays, etc. Compared to Python, you get speed and static type checking.
I couldn't resist throwing in a few random changes of my own: built-in logging and a modified type system that checks for null pointers statically. I also removed all global state (static variables), and various other things I don't approve of.
All highly experimental, of course. Get it while it's hot...