DevAssistant 0.9.0 Released – Getting there

After rather a long pause, we are back with a new version of DevAssistant, this time 0.9.0. This version brings in a bunch of major changes, along with a plethora of bugfixes and little improvements.

The Users

When you run DevAssistant, you can immediately spot the polishing that the creator windows received, where many little usage issues were fixed, text boxes are fully editable, a checkbox is now clickable in situations it wasn’t, etc. etc.

Generally, you will find DevAssistant’s behaviour much more predictable and consistent than it used to be. Amongst larger changes, we would like to point out the Docker support for the Django assistant, heavily improved examples coming with the C/C++ assistants, and a fixed GitHub forking function in the Modify assistant, which now waits until a repo is fully forked so that the user is not confronted with a repo that can not be cloned.

For all those who are using the command line interface, there is some good news in the form of new aliases. The base assistant names (crt, mod, prep) now have a long equivalent to them – create, modify and prepare. We hope that this little change will make using DevAssistant easier for you.

While every little change could be spoken about separately, an experience is worth a thousand words. We encourage you to try then the improved interface by yourself. Details on how to obtain DevAssistant are located at

The Developers

Let us take a look at the things developers who write their own assistants can expect from this new version. For 0.9.0, the syntax was overhauled in a noticeable way with the aim of making it more readable and consistent. Obviously, this means that if you have already written an assistant or two yourself, you may find your assistant incompatible with the new syntax. In that case, we are glad to help you get it fixed quickly (head to our mailing list for help). In any case, read on. We are fairly sure you will what we have done.

There are a couple of things that were added. One of the most evident ones is the tilde. It is a syntactic element that tells the parser in DevAssistant to evaluate the right side of an assignment before the values are stored. This helps greatly if you need to differentiate e. g. between which elements of a list should be evaluated, and which should be assigned verbatim. Also, the rewritten versions of the Ask commands take advantage of this symbol, as you can see in the example below.

  - ask_confirm:
    prompt:  'Is it okay to delete everything?'
    message: '[Y]es or [n]o'

More information about the enhanced syntax and new elements can be found at the Command reference page in Developer documentation.

Another much needed function was sanitizing written user input, so we have added the normalize command, which allows you to effortlessly convert all non-standard characters the users inputs to underscores. This is one of the commands that require using tilde when their results are being assigned to a variable.

Next on the list is a construct that significantly facilitates running commands with elevated privileges. It is the _r suffix, which, in conjunction with the cl (command line) command runner, executes whatever is necessary to run the specified command as root. Example:

cl_r: systemctl start httpd.service

The manner of finding which authentication method and subsequent specifics on different platforms is left to DevAssistant to figure out, so you, as an assistant developer, need not care about any of it. There is one known limitation, though. On Fedora, policykit is used by default, and it does not allow displaying the whole command including parametres that is being run, it just displays e. g. /usr/bin/bash. We are looking at ways to fix this, but we are afraid that there is no way you can have it sooner than in the next version, if not later.

On a related note, if your assistant needs to run commands as a different user, you no longer need to specify that in the command itself. As of now, the command as [username] executes all the commands which it receives as the specified user.

as specific_user:
- cl: run-program --with arguments
- cl_i: run-another-program

Similarly to the *_r* suffix, the particular way of achieving this functionality on different platforms needs not concern the assistant developer and is inferred automatically.

There are two more commands that you may find interesting: github and setup_project_dir. With the first mentioned, we are natively providing support for most common GitHub operations like create a repository, login, push or fork. They are intuitive, using the native GitHub API, so you do not need to care about he details.
The setup_project_dir command is there to relieve developers from having to write the same couple of initial lines in every assistant’s run section, therefore you can specify the directory where project should be created, and this command exports these useful variables for you:

  • $contdir, where the project directory is placed,
  • $topdir, which is the project directory itself, and
  • $topdir_normalized, where all “funny” characters are replaced with underscores. This comes quite handy with e. g. Python, because dashes are not allowed in module names.

For full details on what the syntax in version 0.9.0 is, check out our documentation.

The Contributors

If you want to contribute to DevAssistant, we are more than glad accept your submissions, however starting with this version, we require that bugfixes or new features have their own unit tests where applicable, so that we avoid breaking an already stable piece of code with a fix for something else. Big thanks go to all folks who contribute to DevAssistant. To learn specifics of contributing to DevAssistant, head to our Contributors page.

Last, but not least, it is worth mentioning DevAssistant will now be released much more often, with micro revisions (0.9.x) carrying bug fixes and some minuscule, presumably backwards-compatible changes. New features will now be released only in minor versions (0.10.0). This happens because we want to bring updated versions of DevAssistant into stable releases of distros like Fedora without breaking compatibility. In short, this means you can expect the latest minor version in Fedora’s Rawhide repo, but the stable release will only have new micro revisions of DevAssistant.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>