devassistant (INACTIVE)

devassistant@lists.fedoraproject.org

35 discussions

0.9.0 feature: docker.io containers support
by Bohuslav Kabrda 19 Dec '13

19 Dec '13

Hi all, apart from dependencies versioning, there is another big feature I'd like to implement - working with docker.io containers. I tried to sum this up at issue tracker [1]. What we need to do: * Find out what is the optimal development workflow with docker.io containers. * Add a CommandRunner class that would create these containers. * Document this feature. * Actually use this in default assistant set. Maybe we should modify package managers so that we can reuse them for installing dependencies into containers - but I'm not sure about this. A second option would be to just provide dockerfiles for certain projects, but that would mean that we can't modify the containers/images... Do we want to modify these, too? :) Thanks for all your comments/opinions/suggestions. Slavek. [1] https://github.com/bkabrda/devassistant/issues/143

2 1

0.9.0 feature: dependencies versioning
by Bohuslav Kabrda 09 Dec '13

09 Dec '13

Hi all, I just want to give you all a heads up about a discussion of a feature for 0.9.0 - dependencies versioning support - that takes place at GH issue #127 [1]. I originally wanted to discuss this here, but I'd like to keep the discussion in one place. So if you're interested, please read it through and post your comments at the GH issue. Thanks. P.S.: In the future, I'll probably try to start all of these discussions here and open a tracking bug after the feature is discussed. [1] https://github.com/bkabrda/devassistant/issues/127

1 0

[rfc] DevAssistant Packaging Format + Assistants Repository
by Bohuslav Kabrda 12 Nov '13

12 Nov '13

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.

3 4

Why aren't we using libivirt plugin in Vagrant?
by Peeyush Gupta 11 Nov '13

11 Nov '13

Hi all, In relation to the change proposed here : https://fedoraproject.org/wiki/Changes/Vagrant I was wondering why aren't we using libvirt plugin instead of KVM plugin? The thing is libvirt is used more commonly than KVM, and could result in better implementation. Is there any specific reason for using KVM plugin? Thanks, ~Peeyush Gupta

2 1

[rfc] Intention to Introduce New Assistant Type
by Bohuslav Kabrda 24 Oct '13

24 Oct '13

Hi all, so far, we've had 3 assistant types: creators, modifiers and preparers. I'm starting to think that preparers are in fact hiding two use-cases: - Downloading projects from upstream and setting up environment - Doing something completely unrelated to any specific project (environment setup, just some random stuff) Therefore I believe we should introduce a fourth category, something like "task" assistants (not sure about the name yet, but I can't think of something better). The definition of this category would be the second part of what currently belongs into responsibility of preparers - doing custom tasks unrelated to specific projects. For example, I've had someone ask me to write an assistant that would create a service monitoring audit.log and sending emails to him when a specific content appears. This would probably also include things like a specific type of ide/editor setup (e.g. set up my ide so that I can develop Python projects, but don't import any project into the ide). Thoughts? Thanks, Slavek.

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

devassistant (INACTIVE)