Skip to content
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

return_import_paths parameter #22

Open
seddonym opened this issue Dec 3, 2018 · 1 comment
Open

return_import_paths parameter #22

seddonym opened this issue Dec 3, 2018 · 1 comment

Comments

@seddonym
Copy link
Owner

seddonym commented Dec 3, 2018

We want the graph to make it easy to inspect dependencies between modules as packages rather than just as individual modules.

This needs more thought.

@seddonym
Copy link
Owner Author

seddonym commented Dec 5, 2018

The key is probably to allow any of the methods that return sets of modules to also allow client code to see the import paths for these modules. With the import paths, client code can then go on to use get_import_details for each direct import.

One way to do this would be to have an optional argument return_import_paths, like so:

graph.find_upstream_modules('mypackage.foo') == {
    'mypackage.bar', 'mypackage.baz',
}

graph.find_upstream_modules('mypackage.foo', return_import_paths=True) == (
    {
        'mypackage.bar', 'mypackage.baz',
    },
    (
        ('mypackage.foo', 'mypackage.elsewhere', 'mypackage.bar'),
        ('mypackage.foo', 'mypackage.baz'),
    )
)

This would be the same for find_downstream_modules, find_modules_that_directly_import and find_modules_directly_imported_by. The latter two would be not that useful unless as_packages=True is also passed (otherwise there's no way of knowing which descendants are involved in the direct import).

@seddonym seddonym changed the title Consider how direct import API methods might work with packages return_import_paths parameter Dec 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant