10:13 a.m.
Hello everyone.
Since DevAssistant is about to undergo some major changes (see [1]
for details), I think it would be great to factor in some additional
changes that could make working with DevAssistant even easier than
it's now. For this reason, I'd like to propose another change to the
DevAssistant workflow: storing assistants directly in upstream
repositories with the code they're supposed to work with.
Both myself and Slavek have encouraged developers to create their own
assistants and distribute them in the form of DAP archives. This
approach has caught on quite well for general purpose assistants, like
those for Gnome apps, Vala, or Android SDK [2]. However, we learnt
that developers don't like this format for distributing assistants
used with their particular projects. What I suggest is hearing out the
#1 suggestion of the users themselves: make it possible to include
assistants in the repos they're meant for.
There are a few issues with this approach (talking about those that I
identified. I'm sure you'll find more). The main one is that
DevAssistant is currently stateless, meaning it doesn't remember
anything between invocations (except for some configs stored in
~/.devassistant/config). To work with these assistants, which aren't
installed in a path recognized by DA, I believe it's necessary to
introduce a new functionality; let's call it "da open". When
"opening"
a directory, DevAssistant would load assistants stored in that
directory (more about that below). These assistants would be unloaded
by running "da close". Remembering which directory is "open" would be
straightforward in the client/server architecture described in the
mail linked at [1] - the server would run continuously, remembering
which folders are open for the particular session.
In addition to storing assistants with upstream code, users of
DevAssistant would benefit from storing metadata about their project
in a standardized format, in a file that would also point to the
directory with the assistants. The reason for explicitly selecting the
directory is that if you develop another set of assistants (probably
a new DAP), loading everything in the directory would pick up even the
unfinished assistants you're working on. I believe it's better to let
the user load them only if they really mean to.
To avoid reinventing the wheel for the millionth time, DevAssistant
should use a standard metadata file that's also used by some other
platform. I have looked around, and I believe I found a suitable
solution in the form of the Nulecule specification [3], a
predominantly container-based spec that is used with Project Atomic.
This spec is not strict in its evaluation, leaving DevAssistant with
almost unlimited manœuvering space as far as the metadata format goes,
and be used for many generally useful tags, like author, homepage etc.
A sample file in the Nulecule format would look, for example, like
this:
---
specversion: 0.0.2
id: mydjango-app
metadata:
name: My Django App
appversion: 0.0.1dev
license:
name: GNU GPL v2 or later
url: https://www.gnu.org/licenses/gpl-2.0.html
authors: [ 'Tomas Radej <tradej(a)redhat.com>' ]
homepage: https://example.com/mydjangoapp
devassistant:
assistants: /assistants
minversion: 1.0a
tags: [ atomic, python, django ]
graph:
- name: mydjango-app
---
The "graph" field is there because the Nulecule spec mandates it. For
non-Atomic apps, it isn't important.
In the "metadata > devassistant" field, the location of assistants
would be stored, along with a minimal version of DevAssistant that is
supported by the project, and tags indicating what kind of assistants
can work with this project. I expect these tags to be a full
replacement for the "Project Type" field currently present in
.devassistant files, but not used anywhere. Assistants would then
feature a field called "tag" or "project type" that would be matched
against the tags in the metadata file upon running "da open", and then
presented more prominently than unrelated assistants in the GUI and/or
bash completion in the CLI. More fields can be introduced as necessary.
What do you think? Is there an issue I missed, is this good, or is it
absolute rubbish? Don't hesitate to criticise.
Thanks, Tomas
[1] DevAssistant Mailing List:
https://lists.fedoraproject.org/pipermail/devassistant/2015-April/000065....
[2] DevAssistant Package Index: https://dapi.devassistant.org/
[3] Nulecule GitHub repo: https://github.com/projectatomic/nulecule