[rfc] DevAssistant Packaging Format + Assistants Repository

Tue Nov 12 07:51:45 UTC 2013

On 11/11/2013 02:32 PM, Petr Hracek wrote:
> On 11/11/2013 12:20 PM, Bohuslav Kabrda wrote:
>> 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
>>
By the way dap-lint program should be introduced as well for parsing of 
dap file.
>> 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
> I suggest also to install dependencies on which assistant depends on.
> Like If the assistant requires some package(s) then it should be 
> installed as well during installation process.
>> - 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 (?)
> Shall we use Copr as master repository? Like recommendation.
>> - 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...
> +1
>> Should we allow adding some documentation into the archives?
> Yes, if developer delivers some documentation then we should included 
> them:) Like package in Fedora.
>> - 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)
> No, our assistant should not be uninstallable. Some conflict in Fedora 
> during update. When devassistant-assistants-fedora will be updated 
> then the packages will be installed again.
>
> I suggest:
> /usr/share/devassistant - our assistants only NOT uninstallable
> /usr/local/ - installed devassistant assistants from repository
>> - 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.
>> _______________________________________________
>> devassistant mailing list
>> devassistant at lists.fedoraproject.org
>> https://lists.fedoraproject.org/mailman/listinfo/devassistant
>
>


-- 
Best regards / S pozdravem
Petr Hracek