Support observe("name:items") for ExtensionPoint [Requires Traits 6.1]#354
Conversation
This is achieved by caching the value of ExtensionPoint and make it impossible to mutate the list directly.
|
|
||
| # We shouldn't get a trait event here because we haven't accessed the | ||
| # extension point yet! | ||
| self.assertEqual(None, listener.obj) |
There was a problem hiding this comment.
This test is removed because it is testing the behaviour noted in the "fixme" comment:
# fixme: If the extension point has not been accessed then the
# provider extension registry can't work out what has changed, so it
# won't fire a changed event.
The "fixme" is now fixed.
kitchoi
left a comment
There was a problem hiding this comment.
I will to check for cycle references here, marking as WIP for a bit.
…disconnecting listeners
The reference only serves to support some edge cases where the extension point values become out-of-sync because the listeners are not connected yet. Once the listeners are connected the values are refreshed. So all in all it is not worth keeping the reference, as one will then need to use weakref to avoid cycle references, and special handling in the pickling logic to handle that weakref.
… listeners and trait types
Done. |
|
From offline discussion: The current plan for the next release of Envisage (current version is 4.9.2) is that it will still support Traits 6.0. With that this PR should remain on hold until after the next release. Review is still very welcome though. |
rahulporuri
left a comment
There was a problem hiding this comment.
This LGTM but I would like to test this against internal apps which use envisage to confirm further.
Also, this is a substantial change and I think it might be good to put together a design document accompanying the changes. Do you think that's worth the time?
| warnings.warn( | ||
| "Extension point cannot be mutated directly.", | ||
| RuntimeWarning, | ||
| stacklevel=2, | ||
| ) |
There was a problem hiding this comment.
is it overkill to refactor all of the warnings into a common _raise_warnings method or something of that sort?
There was a problem hiding this comment.
Not an overkill at all... I should do that.
I think it might be good to put together a design document accompanying the changes.
I'd thought that extensive class docstring on _ExtensionPointValue was good enough to explain the rationale, the benefit compared to having a separate design document is that it is close to the code, and therefore it can describe concrete details that can be maintained together. A design document tends to stay high-level and more abstract. Is there any high-level rationale I missed there and does not sit well in the class or module docstring?
There was a problem hiding this comment.
that makes sense too. i think class and module docstrings should be enough.
|
Refactored warning code and merged master in here. However the pickability on Python 3.7+ needs a bit more investigation. |
|
Fixed un/pickling issue. Note that CI is not run against Python 3.7+. I ran the test locally with a venv from Python 3.9 and verified they pass. |
rahulporuri
left a comment
There was a problem hiding this comment.
Changes LGTM. Spending a bit of time testing these changes with internal projects.
Co-authored-by: Poruri Sai Rahul <rporuri@enthought.com>
|
Tested against an internal application and things worked as expected. Still LGTM. I'll maybe spend a bit more time testing against one more internal application. |
I think the next release of envisage will depend on traits >= 6.2.0 so we don't need to worry about adding any additional compatibility layer. |
I will update the |
Done. I believe the |
|
Confirmed offline that this can be merged... merging... |
* Revert "Support observe("name:items") for ExtensionPoint [Requires Traits 6.1] (#354)"
This reverts commit d62af08.
* TST/FIX : Revert test that used observe to listen to changes to
extension point items. The test now uses a static trait change handler
like before
modified: envisage/tests/test_plugin.py
* Revert "Support observe("name:items") for ExtensionPoint [Requires Traits 6.1] (#354)"
This reverts commit d62af08.
* TST/FIX : Revert test that used observe to listen to changes to
extension point items. The test now uses a static trait change handler
like before
modified: envisage/tests/test_plugin.py
* Revert PR #354 (#422) * Revert "Support observe("name:items") for ExtensionPoint [Requires Traits 6.1] (#354)" This reverts commit d62af08. * TST/FIX : Revert test that used observe to listen to changes to extension point items. The test now uses a static trait change handler like before modified: envisage/tests/test_plugin.py * Regression test for #417 (#421) * Add failing test * STY: Fix line spacing issues Co-authored-by: Poruri Sai Rahul <rporuri@enthought.com> * Fix test suite dependence on ipykernel (#423) * Fix hard test suite dependence on ipykernel * Update envisage/tests/test_ids.py Co-authored-by: Poruri Sai Rahul <rporuri@enthought.com> Co-authored-by: Poruri Sai Rahul <rporuri@enthought.com> * DOC : Update changelog modified: CHANGES.rst Co-authored-by: Mark Dickinson <mdickinson@enthought.com>
Closes #291
This PR allows
on_trait_change("name_items")to be migrated toobserve("name:items")where thenameis defined as anExtensionPointtrait.After considering all the constraints and alternative approach (see #291), I have come to the conclusion that the support needs to happen by caching the TraitList returned for the ExtensionPoint and making it impossible to mutate the list directly. Having a persisted list that can change is, strictly speaking, what
on_trait_change("x_items")orobserve("x:items")assumes.This means the list of extensions has to be maintained not just on the extension registry, but on the object with the extension point as well. This requires fair amount of efforts to keep these values in-sync. This PR still treats the extension registry as the single source of truth as to what extensions are available. The ExtensionPoint remains to be a proxy to query values in an extension registry.
Caution: This implementation requires Traits 6.1, as it imports
TraitListfromtraits.trait_list_object. We should decide if it is necessary to phase in Traits 6.1. Should it be decided that the next release of Envisage will still support Traits 6.0, some additional compatibility layer will be needed for this PR. Edited:but I don't think it would be much (We just need to roll the old ExtensionPoint definition for that, that's all.), or this PR can be considered for merging after next release.