Extension point resolution too eager in Envisage 6.0.0 #417
Comments
|
In the short term (this week), we'll revert #354 and push out a bugfix release. |
|
Thanks, @rahulporuri. That should give us some breathing space to add new tests and figure out what the right approach is. |
|
@mdickinson in the meanwhile, it would be good to have a reproducible example, if you already have one. |
|
Yep, I'll see if I can come up with a test. It's probably easier to create an example from scratch than to cut down the project-based example that I have. |
* Add failing test * STY: Fix line spacing issues Co-authored-by: Poruri Sai Rahul <[email protected]>
* Add failing test * STY: Fix line spacing issues Co-authored-by: Poruri Sai Rahul <[email protected]>
* 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 <[email protected]> * 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 <[email protected]> Co-authored-by: Poruri Sai Rahul <[email protected]> * DOC : Update changelog modified: CHANGES.rst Co-authored-by: Mark Dickinson <[email protected]>
|
I know this is a bit LTTP but lazy loading in envisage is a fundamental design principle so this one seems a bit scary. |
|
@mchilvers Indeed. The offending PR was reverted in short order and a bugfix release made, so lazy loading remains. What's left is to figure out how to redo the changes in #354 in a sensible way. |
A project using Envisage 6.0.0 has encountered a serious regression: with Envisage 5.0.0 and earlier versions, when starting an Envisage-based application, all plugins were started before extension point contributions between plugins were resolved. With Envisage 6.0.0, some extension point contributions are resolved while plugins are starting. This means that a plugin that contributes to another extension point can no longer assume that it has already been started, and can no longer depend on traits that happen to be initialised by the
startmethod.(As a side note, initialising traits in the
startmethod is something of an antipattern; that doesn't make this any less of a regression.)The bug appears to have been introduced as a result of #354.
I don't yet have a shareable reproducing example, but I'm working on it.
The text was updated successfully, but these errors were encountered: