----- Original Message -----
> From: "Tomas Radej" <tradej(a)redhat.com>
> To: "General DevAssistant discussion"
> <devassistant(a)lists.fedoraproject.org>
> Sent: Monday, June 8, 2015 5:13:15 PM
> Subject: Distributing Assistants with Upstream Code
>
> 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
The first time I read it I thought that's exactly what I need. But then I
realized that I wouldn't be able to implement the "prep" assistant. Or at
least the "git clone" and/or the "fork" part wouldn't make sense
(because
you need to clone the repository before you can use the assistant and then
you don't want to clone it again). So, I think that it's a good idea but
because of this drawback, I'm still going to stay with the DAPI approach (or
combine them). This is not a complaint, I'm fine with that. I'm mentioning
it just in case you missed that fact (or in hope that I'm wrong and someone
corrects me).
I think this is expected. I'd say that DAPI and this approach don't really overlap
- I'd expect individual projects to ship assistants related just to the project in
their repos (except "prep") and I would expect DAPI to have assistants with more
general target audience. For example, a project would ship a
"prepare-a-PostgreSQL-database-for-developing-this" assistant in it's repo,
while a "create-github-repo" assistant is a good fit for DAPI.
(And in case it's not clear, I'm +1 on Tomas's proposal :))
Slavek
Best regards
--
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech