4 ms·
This looks like a nice distillation of core DAG-running features. I really like the simplicity of `honcho` and will likely try it next time I have a DAG to run
by frumiousirc 3y ago
This looks like a nice distillation of core DAG-running features. I really like the simplicity of `honcho` and will likely try it next time I have a DAG to run that fits in to its model.
I can not help but compare `honcho` to others in this space that I know, particularly `waf` and `snakemake`. I guess these do cover a larger feature space than `honcho` and that comes at the cost of rather greater complexity. I don't think sacrificing the simplicity of `honcho` to add features is necessarily a good thing but I do wonder if / how `honcho` might be used in these ways:
- Execution of a rule adds a new task node to the DAG (a `TaskGen` in `waf`).
- Implicit DAG forming and rule execution (akin to how we define a `rule:` for `snakemake` but it is the system that determines what rules to run and then runs them).
- DAG edge types besides files. Eg, run a downstream rule if some Python data object's value changes (instead of a file change). I believe neither `waf` nor `snakemake` supports this and but one can serialize the Python data to file to make it fit the DAG engine.
- Batteries included such as a cross-platform version of the `c_binary()` function in the `honcho` tutorial. (like `waf` "tools").
- In-system dependency generators (eg `waf` "scanner" pattern).
Thanks for sharing `honcho`!
- frumiousirc 3y agoPS: please assert an explicit license!
- Filligree 3y agoThat assumes it’s supposed to have a license. “Proprietary” is a perfectly reasonable choice.
- codetrotter 3y agoSure but 1. In that case posting the source code to GitHub is less useful 2. More to the point, op said: “Don't like one of Hancho's defaults? It's only 500 lines - hack it up however you like.” I think OP simply forgot to add a license. In which case, reminding them to do so is useful.
- aappleby 3y agoLicense added.
- aappleby 3y agoLicense added
- Jeff_Brown 3y agoTiny point -- it's spelled "hAncho".
- frumiousirc 3y agoOMG! Ha, so embarrassed. Thanks for the correction! It's too late for me to edit. sigh....
- deleted 3y ago[deleted]
- aappleby 3y agoHi, author here. I'm slightly confused by your bullet points - are you asking if Hancho supports these patterns? - "Execution" of a rule can add new task nodes to the DAG (via Rules with command=<async Pythonfunction> - Implicit DAG is there in the form of Rules that depend on promises generated by other Rules. - DAG edge types are just the promises returned by Rules. A custom rule that returns a promise that resolves to an empty array (or a dynamically-populated array) is totally valid - 'Batteries included' rules are out of scope for the base release but I will probably add a default rules.hancho with my preferred C++ build commands. - In-system dependency generators can be as simple as "glob.glob('*.cpp')", or as fancy as you're willing to write.
- frumiousirc 3y agoHi, thanks for the answers! Sorry for lack of clarity but yes, these answers were just what I was hoping to learn.