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(a)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.