devassistant (INACTIVE)
October 2014
devassistant@lists.fedoraproject.org
- 1 participants
- 2 discussions
0.10.0 release, GUI plans and assistant renaming
by Bohuslav Kabrda
Hi all,
here are some proposals for the 0.10.0 DevAssistant release:
- We have bunch of open GUI bugs, but me and Sheldon have been talking to Mizmo about new design. At first, we thought we could have new GUI sketched up very quickly, but it's turning out to be a pretty long process, as we will probably need to do bunch of changes to fulfill some meaningful criteria. This means that I'd like to propose postponing all GUI bugs to the next release (which should be 1.0.0, yay!).
- As part of the UX review, Mizmo has come up with proposal for renaming some assistant types: modify -> tweak, prepare -> import, task -> extras. The first and last I think are great ideas and we should adopt them. The "prepare -> import" change I don't like - I've talked to couple random people and everyone has agreed that "import" feels like importing into IDE that actually has a stateful knowledge about the project. Therefore my proposal here is to rename "modify" to "tweak" and also rename "task" to "extras". I think that we should leave "create" and "prepare" untouched.
- There are still some changes ongoing in the DAPI effort, but Miro is doing a great job and we should have everything (including detailed documentation) ready very soon.
- As noted before, in connection to leveraging DAPI, we'll drop the default assistant set, split it into per-language DAPs and upload to DAPI. Miro is already working on this.
Therefore I'd like to propose that we release DevAssistant 0.10.0 on 10th November 2014, assuming that no more serious bugs are found until then.
0.10.0 should serve as the last version before 1.0.0 - to fix all possible bugs and deficiencies in the portion of new code that we've implemented during past several months. For 1.0.0, we should concentrate on new GUI, fine-tuning DAPI integration, providing PingPong support for more languages, general bugfixing and, ideally, very few major improvements of the core itself. Right now, I'm thinking of just two - versioning dependencies (yeah, let's postpone it again) [1] and advanced arg specfication in Yaml assistants [2].
More about new GUI:
Mizmo sent us some initial sketches, see [3]. They're definitely not final and they include some Mizmo's ideas that I'd like to refuse, if you all agree (merging "modify" and "task" under "tweak" - I only want to rename "modify" to "tweak" without any actual merging; I also don't want to use "import" instead of "prepare", dividing "creator" assistants on languages and frameworks also seems very fragile, people on DAPI won't really have to follow the convention that we've established in our assistant set).
Having said all that, Mizmo is doing brilliant work (look how nice the sketches look!) and I really appreciate talking with her about DA.
Please ask any questions and send suggestions for the new GUI and/or 0.10.0/1.0.0 releases.
Thanks!
Slavek
[1] https://github.com/devassistant/devassistant/issues/127
[2] https://github.com/devassistant/devassistant/issues/26
[3] https://duffy.fedorapeople.org/app%20design/devassistant/
9 years, 5 months
- 1
- 1
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
- 2
- 3
- ← Newer
- 1
- Older →