move example helper modules into examples#805
Conversation
rahulporuri
changed the title
rahulporuri
left a comment
rahulporuri
left a comment
There was a problem hiding this comment.
Almost LGTM - with a bunch of comments/suggestions
| This module provides a simple Pyface application that can be used by examples | ||
| in places where a DemoFrame is insufficient. | ||
| in places where a DemoFrame is insufficient. Note this has been moved to | ||
| sit in enable/examples. This module is kept for backwards compatibility. |
There was a problem hiding this comment.
Let's go with the following for the module docstring - and the warning message as well.
Importing from this module is deprecated. Please use `enable.examples.example_application`
instead. This backwards compatibility stub will be removed in Enable 6.0.
We need an issue to track the removal of these stubs in Enable 6.0
There was a problem hiding this comment.
let's use the above template for the module docstring and warning message in the other stub modules as well.
There was a problem hiding this comment.
Should we say "Please use enable.examples.example_application instead." if we are making the modules private? Theoretically the suggested change is "stop doing that" as opposed to "update your imports"
There was a problem hiding this comment.
Ahh. You're right. Let's update it to
This module is meant for internal use only and it is not meant for use in library code.
Importing from this module is deprecated and it will be removed in Enable 6.0.
We highly recommend that you update your code and vendorize what is necessary.
| # FIXME - it should be enough to do the following import, but because of the | ||
| # PyQt/traits problem (see below) we can't because it would drag in traits too | ||
| # early. Until it is fixed we just assume wx if we can import it. | ||
| # Force the selection of a valid toolkit. | ||
| # import enable.toolkit | ||
| if not ETSConfig.toolkit: | ||
| for toolkit, toolkit_module in (("wx", "wx"), ("qt4", "PyQt4")): | ||
| try: | ||
| exec("import " + toolkit_module) | ||
| ETSConfig.toolkit = toolkit | ||
| break | ||
| except ImportError: | ||
| pass | ||
| else: | ||
| raise RuntimeError("Can't load wx or qt4 backend for Chaco.") |
There was a problem hiding this comment.
I suspect this isn't necessary now.
Co-authored-by: Poruri Sai Rahul <rporuri@enthought.com>
rahulporuri
left a comment
rahulporuri
left a comment
There was a problem hiding this comment.
LGTM. I think making them private is the right thing to do. Let's see if anyone complains.
2 participants
closes #793
This PR simply moves the
enable.example_application,enable.example_canvas, andenable.example_supportmodules to sit in theenable/examplesdirectory. I then did a VSCode find and replace forenable.example_supportwithenable.examples.example_support, etc.Note, as mentioned in this comment: #793 (comment) this may be a breaking change elsewhere as it appears we have down stream users who had directly been importing from these modules. As a result we may not want to push ahead with these changes...Perhaps the old modules should be left around, but simply import from the new modules inenable/examplesand raise some sort of warning? A deprecation warning doesn't really feel correct as it seems to me its more of a "you shouldn't be importing from here" kind of warning.EDIT: I have added stub modules at the old file locations which simply import objects from the new modules and raise a deprecation warning. In the deprecation warning, I did not mention these modules were moved, as we don't want users importing them from anywhere! So I just said importing from here is deprecated and the module will be removed in a future release. Perhaps I should say explicitly don't do this?