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(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
>
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(a)lists.fedoraproject.org
>
https://lists.fedoraproject.org/mailman/listinfo/devassistant
--
Best regards / S pozdravem
Petr Hracek