Yet another 0.9.0 proposal: project types + related changes to .devassistant
by Bohuslav Kabrda
So, this proposal is somehow related to the central assistant index idea:
- I'm assuming (hoping) that people will create lots of creator assistants.
- Creator assistants create .devassistant file and store "subassistant path" in it, e.g. ['python', 'django'].
- Preparer assistants, for example "prep custom" use that to find the original creator and get its dependencies etc.
- With introduction of the central index, it will become likely that people won't have original creators, but will still want to run "da prep custom" and expect that some dependencies will get installed.
Therefore I'd like to propose:
- introducing a catalogue of project types (not sure exactly what it will look like, TBD)
- not explicitly recording "subassistant path" in .devassistant (it will get there among other variables anyway)
- dumping dependencies from creator assistant into the .devassistant file explicitly (e.g. it will contain "dependencies: ...")
And although I like talking to myself on this list, I'd really appreciate some opinions on my latest ideas :)
Thanks,
Slavek.
10 years, 1 month
0.9.0 proposal: Cleaning up Yaml DSL
by Bohuslav Kabrda
So, I've been talking to people who actually tried to use DevAssistant and based on their and my own experience, I'd like to propose that we clean up the Yaml DSL (and extend it in a certain way). Here's the proposal that I've put together:
Current Problems
================
- assigning a literal string value much easier
- assigning a result of expression/section much easier
- more consistent (explicit usage of either literals or expressions for assignments and command runners)
What the Solution Looks Like
============================
This is just an example, move down to see new "walkthrough" that'll guide you through some terminology and how it all works.
run:
- foo: bar # command runner gets literal value
- foo~: $eval and $this # command runner gets expression result
- foo: ~$eval and $this # command runner gets expression result
# some more complicated stuff
- $newdict:
foo: literal
bar: [another, literal]
$eggs~: $eval and $this
pwd~:
- ask_password: something
spam:
- literal
- literal
- ~$eval and $this
- some_command_runner:
- ~$eval and $this
- literal
- - literal
- ~$eval and $this
- - foo~: $eval and $this
- bah: ~$bar and $baz
- spam~: $eval and $this
- spam: dont eval this
run, if/else, for are exceptions - they're execution sections without "~".
Proposed "Walkthrough"
======================
Run is an *execution section* - it consists of an *expression* or a list of *commands*. Expressions consist of variables, brackets and logical keywords, variables start with dollar sign.
Example of an expression:
($foo and $bar) or $baz
In command list, every command is made up of *command type* and *command input*:
- command_type: command_input
- another_command: another_input
Each execution section returns two values - *logical result* (True/False - e.g. success/failure) and *result* (e.g. a return value). Logical result and result of expression is determined by (link to expression rules), logical result and result of a command list are that of the last command. Every command type specifies these differently, see (link).
There are two types of command input - *literal input* and *execution input*.
- Execution input makes DA run the input as an execution section and return its logical result and result.
- Literal input returns a literal value and its logical result (False if empty string/list/mapping, True otherwise).
Literal input is implicit, execution input is triggered by appending "~" at the end of command type. A string can also be made execution input (=> expression) by prepending "~".
- comm_type: literal_input
- comm_type2:
- some
- structured
- literal
- input
- comm_type3~: $execute or $this
- comm_type4~:
- this: is a short run section
- with: some commands
Please send your comments/concerns/ideas.
Slavek.
10 years, 1 month
0.9.0 proposal: Dropping default assistant set and leveraging "assistant index"
by Bohuslav Kabrda
Hi all,
so I've been thinking about this for a while - we should drop the default set of assistants. There's not enough manpower to put all the features that we like into all assistants that we have in default assistant set (sometimes we don't even have time to maintain the default set to work flawlessly with what's already there). So, let's drop it and leverage the central assistant index (after we actually have it of course).
Essentially, DA should be a tool/framework that users will install without assistants. Then they'll get their assistants from the central index with command like "da get someassistant" and then they'll be able to use these assistants.
I'm CCing Miro, who is working on the packaging side of things and on the index - Miro, could you sum up your progress and provide us with the links to repos, etc., so that we all know what's going on?
Comments/thoughts?
Thanks,
Slavek.
--
Regards,
Bohuslav "Slavek" Kabrda.
10 years, 2 months