Introducing Developer Assistant

Another project that I’m working on right now is the so-called Developer Assistant. Its purpose is simple: helping developers with setting up projects in various languages, setting up environment and source control, setting up deployment, installing dependencies etc.

Easier said than done. Devassistant is meant to got to Fedora 19, where it will have just the most basic functionality – setting up various projects in C, Java and Python, other languages support is uncertain at this moment (since it’s being worked on for a month and a half and I have lots of other stuff to do).

So what is it going to look like?

$ devassistant python django -n myproject -e

This will create a basic Django project named “myproject” inside current directory. It will also set up the project as Eclipse PyDev project (-e switch) and set a git repository with sane .gitignore. Before all that, it will install all the needed dependencies.

User Overview

When creating projects, Devassistant is using so-called “assistants” that form a simple hierarchy. E.g. the top assistant (Devassistant itself) has several subassistants like Ruby, Python, C, … Each of these subassistants can have more subassistants etc. The type of the project is specified by the full path in this hierarchy, like in the example above: devassistant python django.

In future versions (Fedora 20?), Devassistant will have assistants like “rpm” for building RPM from a project or “openshift” for Openshift deployment.

Developer Overview

Devassistant is just an engine that can run assistants, which are considered data. For Fedora 19, we will ship this in one package, but before Fedora 20, we will split the packages (and upstream development, too), so that we are able to provide different assistant packages for different systems (RHEL 6 would need different package names than Fedora 19, also the package set is different, …).

The assistants can be written in Python or using Yaml files that follow certain rules. The reason for supporting Yaml assistants is the fact, that Devassistant is written purely in Python and we wanted everybody to be able to contribute in a language agnostic way (Yaml assistants were actually meant to be simple config files, but in short time they got support for conditions, variable assignment and calling sections repeatedly, so they are in fact Turing-complete now).

We welcome all contributions and I’ll be happy to guide you if you have any difficulties.


I’m really looking forward to what people are going to say about this – I hope we’ll get at least some positive comments ;) Enjoy!

9 thoughts on “Introducing Developer Assistant

  1. Pingback: Fedora 19 beta [ + promo video ]

  2. Pingback: Fedora 19 Beta is out | Fedora Project Greece

  3. Pingback: Developer Assistant evolves: Version 0.4 | Slavek's Blog About Fedora and Stuff

  4. Pingback: Fedora 19 Schrödinger’s cat is alive! | Fedora Project Greece

  5. I was just introduced to this this weekend at Wicked Good Ruby Conf from the RHEL booth there. I was wondering if there is a pre-packaged way to quickly install DeveloperAssistant and if said method of installation can be done without sudo / root privilege access?

    I’m tackling a similar problem with my SUPORT ( project. Mine’s a much more specific set of scenarios, but I’m wondering if DeveloperAssistant can help save me a few painful setup from source install processes should it be able to run without sudo. I’ll cross-post this as an issue in the github repo as I don’t see anyone on IRC or an email list setup yet. This idea sounds awesome overall and I hope to see it mature well. Keep up the awesome work!

  6. Hey Steven!
    DevAssistant can be installed by Python’s easy_install or pip (or RPM on Fedora). If you need to install it without sudo privileges, then you can use “pip install –user devassistant” – this will install devassistant and its dependencies into your home directory (on Fedora, for example, it’s “~/.local/lib/python2.7/site-packages/”, assuming that you have pip of course.
    Currently, we also support writing your own assistants and putting them into “~/.devassistant/assistants”, so each user can write/download assistants and install them only for his use. The docs are still being worked on, but should give you the info you need, if you want to write your own assistants.
    As for dependency installation (meaning the packages that devassistant itself installs), we currently distinguish two dependency types:
    – system deps – RPM is the only one currently supported, but these will also be DEBs and stuff – these always need admin privileges to install
    – non-system deps – stuff like Python packages and RubyGems (currently we have support for installation via “pip” and “npm” for Node.js, RubyGem support is comming) – we install these without root privileges into user’s home directory – every language packaging system has a way to do this, so we try to utilize that. So if you write your assistants with e.g.

    – pip: [‘six’]

    User won’t need sudo password to run this.
    As for our communication channels, we’re currently having the mailing list set up, we pop up on irc #devassistant on freenode during day (we all live in CEST timezone currently) and we also have G+ group that you can follow (I created that just yesterday :)):

    The development has been pretty wild few past release cycles, but we mostly manage to keep the Yaml DSL for assistants work. I think that if you write assistant for current version, 0.7.0, they should work ok with 0.8.0 (we’re planning to release that at the end of October).
    Let us know if you have any problems or just impressions, so that we can improve :)
    Are you actually still reading this? :) Great!
    Thanks a lot.

    • tl;dr: It’s on my TODO list (
      The long version:
      There are two sides to this:
      1) When installing system-wide dependencies via RPM or another system package manager, most distributions have just one version of each package in repositories. So in this case, you will be able to make sure that the provided version is the version you want, otherwise the project kickstarting will fail.
      2) When installing dependencies by e.g. pip (either in virtualenv or outside it), you can tell it which version you want – and we will utilize this, so these dependencies will have full versioning support.
      As for Python itself, I’m not sure right now. Fedora always has Python 2.something and Python 3.something – you will be able to choose between those in next version of DevAssistant (0.8.0). As for downloading and compiling arbitrary Python release, I’m not sure, but currently I don’t think we want to support that.

  7. Hi there! Someone in my Myspace group shared this site with us so I came to give it a appear. Im definitely loving the details. Im bookmarking and will likely be tweeting this to my followers! Outstanding blog and great style and style. cffcfbcdeedb

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s