Group: Guix/GSoC-2016

This page is for tracking ideas and process for participating in Google Summer of Code 2016.

Possible topics

Installer wizard for GuixSD

A program that can be bundled with a bootable image which provides an "installer wizard" for the Guix System Distribution. This would walk users through partitioning, setting up users, etc, then set up the disk appropriately, write out the proper Guix system description file, and use it to build the first bootable version of the system.

This could use ncurses or maybe even some graphical toolkit.

Possible mentors:

Packages for foreign distributions

Packages for the guix package manager for Debian/Ubuntu, Fedora/Red Hat/CentOS, etc, to help users of these GNU/Linux distributions come up to speed with Guix much faster. Work to build these packages from within Guix (similar to how we build the "Guix from tarball" install medium). Build a Guix API for the building of Debian and etc packages.

 There is (used to be?) something in Nixpkgs that produces a derivation to build stuff in a Debian VM, build the .deb with CheckInstall, and return that .deb as the derivation’s output.  Something like this is definitely programming, and possibly fun as well.  :-)  -- Ludovic Courtès

Explore hosting "PPA" type resources within Guix's own resources, and work with upstream distributions to explore likelihood of Guix being packaged within those distributions.

Possible mentors:

Graphical package / system manager =

Provide a GUI (ncurses, gtk, or something) for installing, upgrading, and rolling back a user's profile. Do the same for the system profile, and provide a way to configure the system.

Possible mentors:

Arm64 port

Port Guix to Arm64!

Possible mentors:

Guile based build-tool

Guile-based build tool for advanced software developers who do not want to deal with the complexity of multi-platform deployment and dependency hell. By default runs inside the GNU Guix build system and effectively replaces the likes of autotools, cmake, etc.

Build tools such as automake and cmake are complex beasts. What they try to do is target multiple build environments by generating make files using a complex list of string expansions. Complexity, in general, means hard to understand, change and maintain. The bad thing is that almost every software project has to deal with this complexity to make the software deployable.

What is wrong with these build tools? In short:

1. Complex - and therefore hard to understand and maintain

2. Simplistic language - simple string expansion systems are not nice and not DRY

3. Race conditions - make's time stamps are not suitable for building across servers

4. Different combinations of options are badly handled.

5. No intermediate representation

Alternatives, such as Java ant, Scala sbt, and Ruby rake, try to resolve similar issues but are specialised for their environments. Here we have a *fresh* start of a build tool which should ultimately be able to run complex workflows on multiple servers and make use of opportunistic execution, i.e. jobs may be distributed multiple times and the first one that comes back wins.

We primarily targets GNU Guix because Guix already solves the complexity of handling dependencies and software deployment. This simplifies things dramatically because the build system does not have to deal with platform or architecture targets. Even so, in time, we can target out of GNU Guix builds.

Mentors: Pjotr Prins and other Guix members