[rfc] DevAssistant Packaging Format + Assistants Repository

[Bohuslav Kabrda]

Hi all,
I'm planning to start working on $subject, but first I'd like to hear some comments and there are still some questions to answer...

Motivation
==========

- Users want to write assistants that might not be ideal to accept into our distribution.
- Users want to share these assistants, version them, have a place to release them, etc.
- Other users want to search assistants created by others and get these assistants from single database. Ideally, users should be able to do this through "da" binary (or GUI).

Proposal - Packaging Format
===========================

- package is an archive - .dap file (a tar.gz file, just with different extension - I propose to enforce using .tar.gz for the time being)
- can contain multiple assistant
- can contain multiple snippets
- can contain icon for the assistant
- must contain a metainfo file

Structure of dap File
---------------------
(this initial proposal was co-created with Miro Hroncok)

/assistants
    --> {/creator,/modifier,/preparer}
            --> aribitrary subdirs/assistants
/icons
    --> same paths+filenames as in assistants, only different fileexts
/snippets
    --> arbitrary files/dirs
LICENSE
    --> license file (optional, present only if author wants to provide the full license; "license" has to be entered in meta.yaml)
meta.yaml
    --> metainfo


I'm also thinking about having a way to provide some documentation, but let's just go with this for the first version and then extend if needed.

Metainfo
--------

package_name: spam # required
version: 1.0.0 # required
assistants: # required
license: GPLv2 # required
authors: [Bohuslav Kabrda <bkabrda at mailserver.com>, ...] # required
homepage: https://github.com/bkabrda/assistants-spam # required
summary: Some brief text # required
- creator/foo.yaml
- modifier/bar.yaml
- preparer/baz.yaml
icons: # optional
- creator/foo.svg
- modifier/bar.png
snippets: # optional
- spam.yaml
- snippet_subdir/eggs.yaml
bugreports: [<a single url or email address>] # optional
description: Some not-so-brief text # optional

The archive has to be named <package_name>-<version>.dap
Versioning scheme:
- <num>[.<num>]*[dev|a|b]
- Version comparison: 1.0.X < 1.1dev < 1.1a < 1.1b < 1.1 (installing prerelease versions - dev, alpha, beta - will require explicit approval from user, otherwise latest stable version will be installed)

Installation Process
--------------------

- Download the .dap file.
- Check the files inside to see whether we won't get conflict with another installed package.
- Choose the proper devassistant load path to use (e.g. /usr/local/share/devassistant if installing as root, ~/.devassistant if installing as normal user).
- Unpack meta.yaml as <devassistant_load_path>/meta/<package_name>-<version>.yaml
- Unpack assistants, icons and snippets into <devassistant_load_path>/{crt,mod,prep,task,icons,snippets}

Tooling in DevAssistant
=======================

DevAssistant CLI
----------------

- da get <packagename>[-version] # installs from assistants repository or from a local file
- da remove <packagename>[-version] # removes all(?) assistants of given name
- da update [<packagename>[-version]] # updates all (or given) packages to latest version (or given version, if specified)
- [un]installation as root will work with /usr/local/share/devassistant
- [un]installation as normal user will work with ~/.devassistant
- da list # list all installed packages
- da pack path/to/meta.yaml # creates a .dap file
- da upload foo-1.0.0.dap # uploads package to assistants repository

DevAssistant GUI
----------------

- equivalents of CLI

Assistants Repository
=====================

- repository.devassistant.org (?)
- web interface, where
  - users can do fulltext search of assistants
  - users can register
  - authenticated users can upload .dap files
  - authenticated users can rate other assistants (5 star system or something similar) or mark them as dangerous/legally inappropriate
  - admins review assistants marked as dangerous/legally inappropriate and decide what to do with them
- a simple json (or yaml, because we love yaml :)) API for devassistant CLI/GUI
- package names have to be unique


I'm not Sure About...
=====================

Should we mandate that every package installs into separate directories under crt/, mod/, ...?
- Pros: No file collisions between packages.
- Cons: May look silly (crt/[python,python-bkabrda,python-someoneelse,otherpython,...]) and the usage wouldn't be too great...

Should we allow adding some documentation into the archives?
- Probably yes, later on...

What to do with the basic set of assistants that we provide in our distribution? Should they be uninstallable? (They will definitely have to carry their meta.yaml with them)
- Probably uninstallable only if user explicitly chooses to do so, imo. They are in the "third load path" - /usr/share/devassistant - that should not be touched by "da get/da remove", unless sth. like --load-path=/usr/share/devassistant is used.


Still reading? Cool :)
Thanks for your comments.
Slavek.