I recently gave talks at Flock in Krakow and GUADEC in Karlsruhe:
Flock: What’s Fedora’s Alternative to vi httpd.conf Video Slides: PDF ODP
GUADEC: Reworking the desktop distribution Video Slides: PDF ODP
The topics were different but related: The Flock talk talked about how to make things better for a developer using Fedora Workstation as their development workstation, while the GUADEC talk was about the work we are doing to move Fedora to a model where the OS is immutable and separate from applications. A shared idea of the two talks is that your workstation is not your development environment environment. Installing development tools, language runtimes, and header files as part of your base operating system implies that every project you are developing wants the same development environment, and that simply is not the case.
At both talks, I demo’ed a small project I’ve been working on with codename of PurpleEgg (I didn’t have that codename yet at Flock – the talk instead talks about “NewTerm” and “fedenv”.) PurpleEgg is about creating easily creating containerized environments dedicated to a project, and about integrating those projects into the desktop user interface in a natural, slick way.
The command line client to PurpleEgg is called pegg:
[otaylor@localhost ~]$ pegg create django mydjangosite [otaylor@localhost ~]$ cd ~/Projects/mydjangosite [otaylor@localhost mydangjosite]$ pegg shell [[mydjangosite]]$ python manage.py runserver August 24, 2016 - 19:11:36 Django version 1.9.8, using settings 'mydjangosite.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C.
“pegg create” step did the following steps:
- Created a directory ~/Projects/mydjangosite
- Created a file pegg.yaml with the following contents:
base: fedora:24 packages: - python3-virtualenv - python3-django
- Created a Docker image is the Fedora 24 base image plus the specified packages
- Created a
venv/directory in the specified directory and initialized a virtual environment there - Ran ‘
django-admin startproject’ to create the standard Django project
“pegg shell”
- Checked to see if the Docker image needed updating
- Ran a bash prompt inside the Docker image with a customized prompt
- Activated the virtual environment
The end result is that, without changing the configuration of the host machine at all, in a few simple commands we got to a place where we can work on a Django project just as it is documented upstream.
But with the PurpleEgg application installed, you get more: you get search results in the GNOME Activities Overview for your projects, and when you activate a search result, you see a window like:
We have a terminal interface specialized for our project:
- We already have the pegg environment activated
- New tabs also open within that environment
- The prompt is uncluttered with relevant information moved to the header bar
- If the project is checked into Git, the header bar also tracks the Git branch
There’s a fair bit more that could be done: a GUI for creating and importing projects as in GNOME Builder, GUI integration for Vagrant and Docker, configuring frequently used commands in pegg.yaml, etc.
At the most basic, the idea is that server-side development is terminal-centric and also somewhat specialized – different languages and frameworks have different ways of doing things. PurpleEgg embraces working like that, but adds just enough conventions so that we can make things better for the developer – just because the developer wants a terminal doesn’t mean that all we can give them is a big pile of terminals.
PurpleEgg codedump is here. Not warrantied to be fit for any purpose.
fishsoup 
3 Comments
Really cool stuff. I remember the Stateless Linux proposal years ago, and it’s great to see those ideas being revisited.
Working with Docker has made me very aware of one quirk of server-side development – the dependent services. The Web applications that I work on all rely on SQL database services, and some have other dependencies as well (e.g. Redis), so Docker Compose is incredibly useful. Have you any thoughts on how these would tie into the Purple Egg model?
Good question! I think there are two answers, not mutually exclusive:
One possibility is that if the project is using docker-compose, we simply recognize and make things better: start/stop buttons, automatically tail service logs in tabs, etc.
The second is to provide some simple functionality along the lines of docker-compose in the container part of PurpleEgg – someone might want to just have a simple shell along the lines I described, but with mysql running on port 3306.
I think both are potentially valuable – and the question of how a user goes from the second to the first is part of a more general question about how we allow users to add complexity as it is useful for them without deluging the newcomer with all the complexity as soon as they arrive.
That is an interesting problem. I suppose that one way to square the circle would be to use the full Docker Compose, but supply good templates for “pegg create”. Rails smooths the curve for newcomers with code generation: “rails new” and “rails generate” let the user start with a relatively small surface of parameters, but the result has a fairly extensive set of features that they can then explore.