Replace Deprecated API's #11
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
* Replaced packaging.version instead of distutils.version * Replaced imp module to importlib **Note:** Probably Deprecates Python 2.7 supports, and maybe some initial versions of Python 3.x. Signed-off-by: Ameya Vikram Singh <ameya.v.singh@gmail.com>
|
This PR actually fixes the deprecation fix tried earlier in the last PR #10. |
|
Ping, any comments on the changes? |
hohealpen
reviewed
Mar 18, 2023
package/yapsy/PluginManager.py
Outdated
Comment on lines
577
to
587
| candidate_module = None | ||
| if os.path.isdir(candidate_filepath): | ||
| candidate_module = imp.load_module(plugin_module_name,None,candidate_filepath,("py","r",imp.PKG_DIRECTORY)) | ||
| if (spec := importlib.util.spec_from_file_location(candidate_filepath.split('/')[-1], candidate_filepath + "/__init__.py")) is not None: | ||
| candidate_module = importlib.util.module_from_spec(spec) | ||
| sys.modules[plugin_module_name] = candidate_module | ||
| spec.loader.exec_module(candidate_module) | ||
| else: | ||
| with open(candidate_filepath+".py","r") as plugin_file: | ||
| candidate_module = imp.load_module(plugin_module_name,plugin_file,candidate_filepath+".py",("py","r",imp.PY_SOURCE)) | ||
| if (spec := importlib.util.spec_from_file_location(candidate_filepath.split('/')[-1], candidate_filepath + ".py")) is not None: | ||
| candidate_module = importlib.util.module_from_spec(spec) | ||
| sys.modules[plugin_module_name] = candidate_module | ||
| spec.loader.exec_module(candidate_module) |
There was a problem hiding this comment.
Legibility suggestion: this would be easier to understand and offer a cleaner traceback (if/upon error) if refactored into separate path munging and conditional spec assignment/exec. Does this seem logically equivalent?
candidate_module = None
filepath_base = candidate_filepath.split('/')[-1]
if os.path.isdir(candidate_filepath):
location = candidate_filepath + '/__init__.py'
else:
location = candidate_filepath + '.py'
if (spec := importlib.util.spec_from_file_location(filepath_base, location)):
candidate_module = importlib.util.module_from_spec(spec)
sys.modules[plugin_module_name] = candidate_module
spec.loader.exec_module(candidate_module)
return candidate_moduleThere was a problem hiding this comment.
Makes sense, updated the PR with the suggestions.
|
Is there anything else I need to take care of e.g.: Updating the versioning details? |
|
Hello ! Nothing is missing in it but since this is definitely breaking the pyhon2 compatibility, I had to push a few commits to make the transition a bit more explicit and clean before merging the breaking change. |
AdamWill
added a commit
to AdamWill/nikola
that referenced
this pull request
Jul 14, 2023
tibonihoo/yapsy#11 changes yapsy plugin loading to not use the deprecated imp module any more. However, as a side effect of that, it breaks this already-kinda-ugly hack, and we have to make it even uglier! yapsy used to import the module like this: imp.load_module(plugin_module_name,plugin_file...) where `plugin_module_name` was the modified, "unique" name it creates early in `loadPlugins`. Interestingly, when you import a module like that, it gets added to `sys.modules` under *both* the modified name and its 'real' name, viz: >>> import sys >>> import imp >>> imp.load_module("someothername", None, "/usr/lib/python3.12/site-packages/yapsy/__init__.py", ("py", "r", imp.PKG_DIRECTORY)) <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["someothername"] <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["yapsy"] <module 'yapsy' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> That's why this hack worked. However, now yapsy imports the module using importlib, then adds it to `sys.modules` itself, *only* under the modified "unique" name, not under its original name. So sys.modules["unmodifiedpluginname"] is now a KeyError. I can't think of a less ugly fix than this, unfortunately. We *could* try sending a patch for yapsy to add it under both the modified and unmodified names, but that would be somewhat tricky in yapsy's design, and I also suspect yapsy would consider it to actually be unwanted behavior. Maybe what we really need is to send a patch for yapsy to just provide an interface to find a plugin's filesystem path... Signed-off-by: Adam Williamson <awilliam@redhat.com>
AdamWill
added a commit
to AdamWill/nikola
that referenced
this pull request
Jul 14, 2023
tibonihoo/yapsy#11 changes yapsy plugin loading to not use the deprecated imp module any more. However, as a side effect of that, it breaks this already-kinda-ugly hack, and we have to make it even uglier! yapsy used to import the module like this: imp.load_module(plugin_module_name,plugin_file...) where `plugin_module_name` was the modified, "unique" name it creates early in `loadPlugins`. Interestingly, when you import a module like that, it gets added to `sys.modules` under *both* the modified name and its 'real' name, viz: >>> import sys >>> import imp >>> imp.load_module("someothername", None, "/usr/lib/python3.12/site-packages/yapsy/__init__.py", ("py", "r", imp.PKG_DIRECTORY)) <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["someothername"] <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["yapsy"] <module 'yapsy' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> That's why this hack worked. However, now yapsy imports the module using importlib, then adds it to `sys.modules` itself, *only* under the modified "unique" name, not under its original name. So sys.modules["unmodifiedpluginname"] is now a KeyError. I can't think of a less ugly fix than this, unfortunately. We *could* try sending a patch for yapsy to add it under both the modified and unmodified names, but that would be somewhat tricky in yapsy's design, and I also suspect yapsy would consider it to actually be unwanted behavior. Maybe what we really need is to send a patch for yapsy to just provide an interface to find a plugin's filesystem path... Signed-off-by: Adam Williamson <awilliam@redhat.com>
AdamWill
added a commit
to AdamWill/nikola
that referenced
this pull request
Jul 14, 2023
tibonihoo/yapsy#11 changes yapsy plugin loading to not use the deprecated imp module any more. However, as a side effect of that, it breaks this already-kinda-ugly hack, and we have to make it even uglier! yapsy used to import the module like this: imp.load_module(plugin_module_name,plugin_file...) where `plugin_module_name` was the modified, "unique" name it creates early in `loadPlugins`. Interestingly, when you import a module like that, it gets added to `sys.modules` under *both* the modified name and its 'real' name, viz: >>> import sys >>> import imp >>> imp.load_module("someothername", None, "/usr/lib/python3.12/site-packages/yapsy/__init__.py", ("py", "r", imp.PKG_DIRECTORY)) <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["someothername"] <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["yapsy"] <module 'yapsy' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> That's why this hack worked. However, now yapsy imports the module using importlib, then adds it to `sys.modules` itself, *only* under the modified "unique" name, not under its original name. So sys.modules["unmodifiedpluginname"] is now a KeyError. I can't think of a less ugly fix than this, unfortunately. We *could* try sending a patch for yapsy to add it under both the modified and unmodified names, but that would be somewhat tricky in yapsy's design, and I also suspect yapsy would consider it to actually be unwanted behavior. Maybe what we really need is to send a patch for yapsy to just provide an interface to find a plugin's filesystem path... Signed-off-by: Adam Williamson <awilliam@redhat.com>
3 tasks
AdamWill
added a commit
to AdamWill/nikola
that referenced
this pull request
Jul 15, 2023
tibonihoo/yapsy#11 changes yapsy plugin loading to not use the deprecated imp module any more. However, as a side effect of that, it breaks this already-kinda-ugly hack, and we have to make it even uglier! yapsy used to import the module like this: imp.load_module(plugin_module_name,plugin_file...) where `plugin_module_name` was the modified, "unique" name it creates early in `loadPlugins`. Interestingly, when you import a module like that, it gets added to `sys.modules` under *both* the modified name and its 'real' name, viz: >>> import sys >>> import imp >>> imp.load_module("someothername", None, "/usr/lib/python3.12/site-packages/yapsy/__init__.py", ("py", "r", imp.PKG_DIRECTORY)) <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["someothername"] <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["yapsy"] <module 'yapsy' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> That's why this hack worked. However, now yapsy imports the module using importlib, then adds it to `sys.modules` itself, *only* under the modified "unique" name, not under its original name. So sys.modules["unmodifiedpluginname"] is now a KeyError. I can't think of a less ugly fix than this, unfortunately. We *could* try sending a patch for yapsy to add it under both the modified and unmodified names, but that would be somewhat tricky in yapsy's design, and I also suspect yapsy would consider it to actually be unwanted behavior. Maybe what we really need is to send a patch for yapsy to just provide an interface to find a plugin's filesystem path... Signed-off-by: Adam Williamson <awilliam@redhat.com>
AdamWill
added a commit
to AdamWill/nikola
that referenced
this pull request
Jul 15, 2023
tibonihoo/yapsy#11 changes yapsy plugin loading to not use the deprecated imp module any more. However, as a side effect of that, it breaks this already-kinda-ugly hack, and we have to make it even uglier! yapsy used to import the module like this: imp.load_module(plugin_module_name,plugin_file...) where `plugin_module_name` was the modified, "unique" name it creates early in `loadPlugins`. Interestingly, when you import a module like that, it gets added to `sys.modules` under *both* the modified name and its 'real' name, viz: >>> import sys >>> import imp >>> imp.load_module("someothername", None, "/usr/lib/python3.12/site-packages/yapsy/__init__.py", ("py", "r", imp.PKG_DIRECTORY)) <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["someothername"] <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["yapsy"] <module 'yapsy' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> That's why this hack worked. However, now yapsy imports the module using importlib, then adds it to `sys.modules` itself, *only* under the modified "unique" name, not under its original name. So sys.modules["unmodifiedpluginname"] is now a KeyError. I can't think of a less ugly fix than this, unfortunately. We *could* try sending a patch for yapsy to add it under both the modified and unmodified names, but that would be somewhat tricky in yapsy's design, and I also suspect yapsy would consider it to actually be unwanted behavior. Maybe what we really need is to send a patch for yapsy to just provide an interface to find a plugin's filesystem path... Signed-off-by: Adam Williamson <awilliam@redhat.com>
Kwpolska
pushed a commit
to getnikola/nikola
that referenced
this pull request
Jul 15, 2023
tibonihoo/yapsy#11 changes yapsy plugin loading to not use the deprecated imp module any more. However, as a side effect of that, it breaks this already-kinda-ugly hack, and we have to make it even uglier! yapsy used to import the module like this: imp.load_module(plugin_module_name,plugin_file...) where `plugin_module_name` was the modified, "unique" name it creates early in `loadPlugins`. Interestingly, when you import a module like that, it gets added to `sys.modules` under *both* the modified name and its 'real' name, viz: >>> import sys >>> import imp >>> imp.load_module("someothername", None, "/usr/lib/python3.12/site-packages/yapsy/__init__.py", ("py", "r", imp.PKG_DIRECTORY)) <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["someothername"] <module 'someothername' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> >>> sys.modules["yapsy"] <module 'yapsy' from '/usr/lib/python3.12/site-packages/yapsy/__init__.py'> That's why this hack worked. However, now yapsy imports the module using importlib, then adds it to `sys.modules` itself, *only* under the modified "unique" name, not under its original name. So sys.modules["unmodifiedpluginname"] is now a KeyError. I can't think of a less ugly fix than this, unfortunately. We *could* try sending a patch for yapsy to add it under both the modified and unmodified names, but that would be somewhat tricky in yapsy's design, and I also suspect yapsy would consider it to actually be unwanted behavior. Maybe what we really need is to send a patch for yapsy to just provide an interface to find a plugin's filesystem path... Signed-off-by: Adam Williamson <awilliam@redhat.com>
Open
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.
Note: Probably Deprecates Python 2.7 supports, and maybe some initial versions of Python 3.x.