Re: Distributing Assistants with Upstream Code

[Radek Holy]

----- Original Message -----
>  From: "Tomas Radej" <tradej(a)redhat.com&gt;
>  To: "General DevAssistant discussion"
> <devassistant(a)lists.fedoraproject.org&gt;
>  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&gt;&#39; ]
>     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
>  _______________________________________________
>  devassistant mailing list
>  devassistant(a)lists.fedoraproject.org
>  https://lists.fedoraproject.org/mailman/listinfo/devassistant
>   
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).

Best regards
-- 
Radek Holý
Associate Software Engineer
Software Management Team
Red Hat Czech