Here’s your digest for today! #ariatosca undefined: congrats on migrating the website undefined: [UPDATE] we now have resumable workflows - that is, every workflow is now resumable undefined: hey guys, i want to make a suggestion: let's move the execution plugin to be an extension. i know it's an important default plugin, but especially with SSH support being optional now, it seems to make more sense to me. again, the goal is to keep the core as minimal as possible here.
it might also make sense for uses to be able to configure the default plugin. for example, i can imagine someone forking the execution plugin to use a different kind of SSH mechanism or a different kind of CTX proxy (if at all). these issues seem like implementation details for ARIA execution that some users might want to be different. some cloud environments, for example, might have a built-in execution framework that people would want to be the default. undefined: +1 doing more stuff in plugins makes your binary releases easier you can keep a stable core, release small plugins incrementally also makes everything option and avoid licensing problems undefined: <@U4RAXBZ1Q> we would still consider this a "core plugin", meaning that it comes with the core distribution and has the same release cycle. of course the mechanism also supports "external plugins" that would come from other repositories. the loading mechanism is identical for core or external plugins. the distinction is made purely to simplify project management and releases. i think the way we handled ssh support is very reasonable. it is an extra feature added to core execution plugin via installing a simple package dependency. this is much easier for everyone than separating it into a separate code repository with its own release cycle. of course more complicated cases in the future might indeed demand separate repos. undefined: [UPDATE] so, despite setbacks (computer failures) lots of progress on our code documentation. there were so many sphinx errors, a huge mess of things, but i'm slowly marching through and making sure it at least generates. `Click` decorated methods cannot be normally documented by sphinx due to how poorly their decorators are designed. i had some success patching them, until i realized it's just not worth maintaining a patch just for documentation. instead, we'll be using a sphinx plugin for click that generates cli documentation directly from the classes! it looks quite nice and is actually a much better solution. :slightly_smiling_face: however (always a however) it doesn't sanitize ReST markup when it does this. so, for best results the cli documentation should be as neutral as possible, so it would look good on the terminal and good in sphinx. one weird edge case was the use of "*" in one helptext, which ReST interprets to mean the beginning of an emphasis... more serious issues, as you might expect, come from sqlalchemy's declarative mechanism. i introduced one fix to make sure that at least the documentation will be generated, but otherwise the mixins create a whole range of errors. i think they might be related to this sphinx issue, which apparently was just fixed this week and might see a release soon: <https://github.com/sphinx-doc/sphinx/issues/3866> without that fix, we are getting a crapload of big red warnings, but the documentation is generated correctly. i think i might be able to finish everything tomorrow, or at least over the weekend, but it's not entirely terrible right now. #random #general
