move example helper modules into examples #805
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rahulporuri
changed the title
rahulporuri
approved these changes
Jun 21, 2021
enable/example_application.py
Outdated
Comment on lines
14
to
16
| 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.
enable/examples/example_support.py
Outdated
Comment on lines
21
to
35
| # 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.
rahulporuri
reviewed
Jun 21, 2021
Co-authored-by: Poruri Sai Rahul <rporuri@enthought.com>
rahulporuri
approved these changes
Jun 21, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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?