0.10.0 proposal: Executable assistants
by Bohuslav Kabrda
Hi,
so after some time I have a proposal for DevAssistant again, I call it "Executable assistants".
What:
Let's allow writing assistants in scripting languages in addition to the Yaml DSL.
Why:
During my hallway-talks with many people on various conferences, I found out that approximately a third of potential DA users are scared/confused/... by the Yaml DSL. Typical arguments include "there's no point in learning the DSL, I can't use that knowledge anywhere else", "I already know <Language X>, I don't want to learn something new", etc...
While I think that the DSL is good in what it does, I can understand why some people don't want to learn it, for some it's even an uncrossable barrier - and I don't want to loose these potential users. Also, I admit that our DSL is not ideal for some types of tasks.
How:
There are basically two ways to achieve this, but both use a common idea, that I like to think of as "ping pong": DA runs the "executable assistant" as a subprocess and communicates with it through a pipe. DA tells the assistant what user wants and the assistant does anything it wants. For complex functionality, the assistant can reach out to DA through the pipe and say e.g. "hey, I need to create a Github repo for this user"; DA does that, returns result to the assistant through pipe and assistant continues running again. And so on...
Ideally, we would have libraries in all major scripting languages that would make the communication through the pipe very easy (see the example below).
Now for the two ways to achieve this:
1) The assistant will be just a single script file. When DA is invoked, it asks this script file for it's arguments, then for dependencies and then it tells it to run.
2) The assistant is a reasonably small Yaml file (description, args, dependencies) and a script file. The Yaml file is read by DA to get description, arguments and dependencies; the script file itself is only run when the assistant is actually invoked.
I'm leaning towards 2), since:
- With 2) DA wouldn't have to run subprocesses (possibly a lot of them) to get assistant arguments to construct argument parser; it'd still just read Yaml files this way (=>fast)
- With 1), user would have to already have the scripting language (in which assistant is written) installed, which brings another complex problem to solve. With 2), the Yaml file can just list the scripting language in dependencies.
- With 2), we could transform this approach to a command runner, e.g. people would be able to use DSL and use a scripting language for just a part of the assistant.
The disadvantage is that people would have to learn a small subset of the Yaml DSL (e.g. specifying dependencies and arguments), but that should be easy and intuitive enough (as opposed to run sections, which are much more complex).
An example of how the Yaml part would look like:
### Start foo.yaml
name: Foo
description: Some Foo description
args:
name:
flags: [-n, --name]
help: Project name
dependencies:
- rpm: [python3] # the executable assistant is written in Python 3, so let's install it
run:
# delegate the control to the script
- pingpong: python3 script.py
### End foo.yaml
And the pingpong script (I really still haven't thought about the precise form of this, this is just what it *might* look like):
### Start script.py
import dapp
class Assistant(dapp.ExecutableAssistant):
def run(self, context, possibly_more_arguments, ...):
project_name = context['name']
username = compute_username_by_a_very_complex_method()
self.run_command('github_create', username, project_name)
# continue computing ...
return (True, 'some_return_value')
### End script.py
Sounds good?
Thanks a lot for all comments!
--
Regards,
Slavek Kabrda
9 years, 6 months
Checking out on Github
by emc
Hello,
my name is Enrico and I tried to install devassistant via Github after I
read about it in the Fedora.21 changes.
At the moment it doesn`t fit to install. If I try to start it (after
installing) ("da prepare devassistant") I just get a "da unknown"-message.
Version-numbers of dependencies:
Python2.75 // Python3.3.2
polkit0.112
pygobject3-3.10.2
I also installed the dependencies from requirements-devel.txt.
Maybe you can help me to find the bug.
Kind regards
Enrico
9 years, 6 months
Features for 0.10.0
by Bohuslav Kabrda
Hi all,
me and Sheldon have already created a list of issues for DevAssistant release 0.10.0 [1] (ok, it's mostly work of Sheldon :))
Anyway, I'd like all interested to look at it and possibly suggest what else we should implement/fix. Currently planned "big features" are:
- DNF package manager, so that we can make DA run on Python 3 as a default in Fedora [2]
- Github 2 factor authentication [3]
- Versioning dependencies [4]
- "Exectuable assistants" - a proposal that I'll be sending here in a couple of minutes (assuming people like it, of course)
- assistant packages and "DevAssistant Package Index" integration - something that has already been proposed [5] and has been taking long to implement, but we finally have a pre-alpha version [6], I'll ask Miro to send some instructions on how to test
Sheldon has also asked Mo Duffy, a UX designer, to review DA GUI. We may or may not try to implement some improvements based on the review, depending on how much time we have left.
One more thing that I'd like to do with GUI is ... rewriting it in Qt. It may be just my feeling, but I think that Qt looks nicer, is more portable and *stable* (and integrates well with gnome-shell). But then again, it's about having enough time to do this... Any objections, comments?
Please comment and/or propose other features that should be implemented.
--
Regards,
Slavek Kabrda
[1] https://github.com/devassistant/devassistant/issues?q=is%3Aissue+mileston...
[2] https://github.com/devassistant/devassistant/issues/270
[3] https://github.com/devassistant/devassistant/issues/165
[4] https://github.com/devassistant/devassistant/issues/127
[5] https://lists.fedoraproject.org/pipermail/devassistant/2014-February/0000...
[6] http://dapi.devassistant.org/
9 years, 7 months
