DummyModule doesn't seem to respect nested source files

[oldskoolfan]

Setup

I have a script that is initializing the Target class and calling the pydeps.externals function to discover dependencies (both my own and third party) in my codebase. I have a monorepo with multiple apps and a shared lib folder, so when running my script I am modifying the PYTHONPATH to include my app and lib folders. The reason for this setup is so I can dynamically build any app in my monorepo and only include the shared modules it needs.

Problem

The issue I ran into is if we have a module in the shared lib folder that is not a directory, but just one python file, the DummyModule class fails to find it due to the relative path. E.g. for a file proj_root/lib/shared_module.py, the DummyModule class tries to open proj_root/shared_module.py which can't be found.

Example error: FileNotFoundError: [Errno 2] No such file or directory: shared_module.py

Possible solution

I noticed in pull request for issue #179 in the is_pysource logic, self.fname = target.calling_fname was changed to self.fname = target.fname. I reverted that line to its previous logic and my script worked as expected. Since the code was changed to address the scenario in #179, I was curious if some sort of flag or parameter for the Target class could be introduced to handle my scenario as well.

[thebjorn]

We're solving a similar problem internally by using virtualenvs and editable installs (pip install -e <package>), which sounds like it tries to work within Python's expected modus operandi - although I'm sure your PYTHONPATH manipulations are more flexible...

I'm not fundamentally opposed to a flag that turns on the behavior you're seeking (defaulting to the current behavior). I'll gladly merge a PR that implements this as long as it contains a test (that only passes with the new flag)...