Pagure and Fedora

There are a fair number of options for project hosting these days, from the largely moribund SourceForge to the ever-popular GitHub, but many of these sites either do not release their software or are largely company-run projects, without much in the way of an external development community. A relatively new entrant in the "forge" scene (where "forge" hearkens back to SourceForge, which was one of the earliest) is pagure. It is gaining a bit of traction as the Fedora project has started using it for some of its projects. One of its headline features, that distinguishes it from some other project-hosting tools, is that the discussion metadata for bugs and pull requests is also available, which allows projects to easily move or to keep multiple pagure instances in sync.

Python and Git

Pagure is written in Python and uses Git for its repositories. It includes the usual set of features that projects have come to expect from this type of package, like issue tracking, repository forking, pull requests, and so on. Its genesis is in the Fedora infrastructure project and it was originally called "progit" by its creator Pierre-Yves Chibon.

As would be expected, the project itself is hosted within pagure, which easily allows those interested to browse its documentation and issues (bugs and feature requests). On the main page for a repository, there are the expected URLs for the source code Git repository and (a bit hidden behind a "more" link on the project page) a Git repository for the documentation. While the issues and pull-request information is also stored in Git repositories, URLs for those are not apparent (or at least obvious) in the web interface. There is also scant mention of those repositories in the documentation, which is a little bit sparse at this point.

One of the big complaints about GitHub is that much of the metadata that a project accumulates is not easily retrieved should the project want to move elsewhere. Making that easier, while also allowing other use cases such as synchronization between multiple project sites, is one of the more interesting features of pagure.

Installation and workflow

Installation from source into a Python virtual environment is fairly straightforward as described on the main project page. Installing on Fedora or RHEL/CentOS can be done using RPMs or, for other distributions, setup.py can be used. There are some fairly lengthy instructions on configuring the web server, setting up repository directories, and creating the database once pagure itself has been installed.

By default, pagure uses SQLite, but that is not sufficient for running a production instance, so either PostgreSQL, MySQL, or MariaDB need to be available for those types of systems. For managing updates to the database tables, the Alembic "lightweight database migration tool" is used. It works with the SQLAlchemy database toolkit for Python to allow the database schema to evolve relatively painlessly as pagure adds new features.

The workflow in pagure is fairly easy to pick up as it should be familiar to those who have used GitHub or similar sites. Repositories are forked and modified, then submitted back to the project as pull requests. In addition, pull requests can be created from forks that are hosted elsewhere and changes pushed into a branch that a pull request was created from will automatically update the request with the new changes.

Architecture

The architecture of the tool is based on a number of cooperating processes. The main application is a Flask-based web application that provides a user interface to the Git repositories, issues, and pull requests. Gitolite is used to control SSH access to the repositories. The documentation server is a separate web application that can (and probably should) be hosted on its own system:

Beyond that, there is a "milter" (mail filter) that allows people receiving comments on issues or pull requests to reply directly in email and have their message be added—alleviating the need to call up the web page before replying. There is an "EventSource" server that handles live refreshing of web page contents (such as comments on an issue being viewed). The "web-hook" server handles third-party notifications, such as to Fedora infrastructure's fedmsg message bus.

Releases for pagure are coming at a fairly quick pace. The project appears to be a little more than a year old and, unlike many projects that languish with 0.x releases for years, is up to version 2.1.1. The 1.0 release was made back in January; Fedora Magazine reviewed at that time, noting that the name comes from the French word for "hermit crab". In his post announcing that the project was being renamed, Chibon explained the connection: "This little crab moves from shell to shell as it grows up. I found it was a nice analogy with this forge where [a] project can move from place to place."

As with many projects these days, pagure has a list of easy fixes for those who want to get involved. A look through the issue tracker will provide a sense for where things may be headed. For example, Python 3 support is in the plans, and there is a "py3_work" branch where that work is going on, though, at this point, running pagure on Python 3 is a bit of a "bumpy ride", Chibon said.

Overall, it seems like an interesting project that fills an important niche, though it is not the only project of that sort. For example, Kallithea is a free-software, Python-based forge with both Git and Mercurial support. It is GPLv3-licensed, rather than the GPLv2 chosen by pagure, but the goals of the projects are similar. Some may question the need for both.

In some sense, Fedora project leader Matthew Miller touched on that with an issue (tagged "wishful") he posted about integrating pagure with the Taiga project management platform. He was concerned that pagure was not getting enough traction to attract a development community outside of the Fedora world, not to mention that it was adding yet another bug tracker for Fedora.

While pagure certainly seems like a nice tool, there is a risk of "too many" efforts like these. A major part of GitHub's appeal is the network effects that come from many developers already having an account with the service and the knowledge of how to use it. Splitting the free-software community's attention into multiple different platforms, each with its own idiosyncrasies, accounts, and so on, may not lead to a freedom-focused alternative and, instead, continue the fractured landscape we see today. On the other hand, there may be ways to link up pagure, Kallithea, and others to create some kind of federated, free meta-forge for hosting projects—one that is large enough to benefit from network effects of its own.

[ Thanks to Bruno Wolff III for suggesting the topic. ]