New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to restrict ModuleFinder to get "direct" dependencies #42354
Comments
this patch add a parameter to ModuleFinder, to not With the current system, you cannot create a clean This patch do not change the default behavior. |
Logged In: YES Thomas are you the defacto maintainer of modulefinder? Any |
I have no time or interest in this patch, so unassigning. |
Anyone interested in this or can it be closed? |
Adding jvr and people interested in import machinery, per Misc/maintainers.rst Michael, can you refresh your patch against the py3k branch? Please also generate a unified diff from the top level of the source distribution, as detailed in http://www.python.org/dev/patches/ The feature seems useful to me and the patch is straightforward. Tests and doc updates are needed; do you want to add them? Mark, I think that feature requests are never closed just because they’re old; they have to be rejected, implemented or obsoleted. (Thank you for all your triage work.) |
The generalist in me is inclined to suggest a "depth" parameter (with depth=1 equivalent to direct dependencies only, and depth = None meaning all dependencies), but I must admit I don't have a concrete use case for the extra generality. So the simpler, recurse/don't recurse approach is probably a better option (building a depth-limited search on top of the recursion flag wouldn't be difficult anyway). Aside from missing docs and unit test updates, the idea seems sound. |
Although I do find it a little concerning that there is no mention of sys.path_hooks or sys.meta_path in the modulefinder source code. I suspect this module only works correctly with vanilla filesystem based imports and can't handle anything imported via PEP-302. |
The depth parameter idea sounds like YAGNI, so let’s stay with a recurse boolean :) |
I applied the patch, added a test and found a bug. Here’s my progress so far; someone can start from it to write more tests and fix the code. |
I modernized modulefinder a bit in 1521d9837d16; here’s a refreshed patch. |
I would like to help with this issue. I note the history (using Git Dag) of the modulefinder.py shows that it has been modified with changes related here: Author: Éric Araujo <merwok@netwok.org> 2011-07-28 22:35:29
and Author: Éric Araujo <merwok@netwok.org> 2011-08-01 14:29:07
And the modulefinder.py file has been subsequently modified by another 28 changes. So I am wondering if this issue is still relevant? |
Mike, from looking at the code the change proposed here is not there, so while the patch may not apply cleanly anymore, the commits you mention do not make this issue irrelevant. |
Ok, I will work on this soon and make further comments. |
I have made the changes as indicated in the diff files. I have tested against the latest from my GitHub copy. The first diff is attached. But there was a bug in the code and I will upload in next comment. |
Minor fix after test. |
Mike's fix unfortunately didn't work out. What are the rules about closing old enhancement requests? modulefinder is an old and rarely used package, and I feel like the use case is better served by a PyPI package. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: