ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Slack" <>
Subject [Slack] Notifications from the ASF team for June 23rd, 2017 at 8:17 AM
Date Fri, 23 Jun 2017 05:17:27 GMT

You have a new direct message from the ASF team


View in the archives:

Digest.AI (8:01 AM, June 23rd)
*Here’s your digest for June 23rd 2017*
There are 13 messages yesterday, and the most active user is Tal Liron

 @emblemparade: 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.
 @johndament: +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
 @emblemparade: @johndament 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.
 @emblemparade: [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

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.

* * *

You can snooze these notifications for
an hour:
eight hours:
a day:
three days:
or the next week:

You can also turn email notifications off:

For more detailed preferences, see your account page:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message