Feature/proxy attribute forwarding #215
Conversation
sebclrsn
requested review from
sebastianpfischer,
TedRio and
BKaDamien
and removed request for
TedRio
Codecov Report
@@ Coverage Diff @@
## master #215 +/- ##
==========================================
+ Coverage 95.37% 95.40% +0.03%
==========================================
Files 72 72
Lines 5551 5577 +26
==========================================
+ Hits 5294 5321 +27
+ Misses 257 256 -1
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
docs/whats_new/version_ongoing.rst
Outdated
| each auxiliary that has to share it, ``pykiso`` will do the rest for you. | ||
|
|
||
|
|
||
| Remove reduncancy of activate_log configuration parameter |
There was a problem hiding this comment.
| Remove reduncancy of activate_log configuration parameter | |
| Remove redundancy of activate_log configuration parameter |
| attached to the created :py:class:`~pykiso.lib.auxiliaries.proxy_auxiliary.ProxyAuxiliary` | ||
| is still possible, but keep in mind that if one auxiliary modifies one the communication | ||
| channel's attributes, every other auxiliary sharing this communication channel will be | ||
| affected by this change. |
There was a problem hiding this comment.
I think we should illustrate that with a python snippet somewhere
There was a problem hiding this comment.
To me it is sufficient to have this behaviour explained with text and then illustrated with the schema linked below, adding a code snippet here will add a lot of content for a side-note the user shouldn't usually have to care about
|
Please separate the PR in 2 with clear descriptions for each and the feature you want to add. Thanks! |
See #223 |
This PR implements the cchannel API forwarding mechanism discussed as partial solution 2 for complex connectors.
It also fixes the activate_log functionality so that when loggers are activated by one auxiliary, they aren't deactivated by the following ones