mgedmin / findimports

Static analysis of Python import statements
MIT License
117 stars 16 forks source link

Namespace packages #22

Open smurfix opened 2 years ago

smurfix commented 2 years ago

I'm trying to use findimports with namespace packages (i.e. those which don't have an __init__ in their directory tree) and I'm running into some issues.

First, the directory structure:

$ tree
.
├── Makefile
├── moat
│   └── main
│       └── __init__.py
├── README.md
├── setup.cfg
└── setup.py

There's a ../util directory alongside this one which has much the same structure:

 tree ../util
../util
├── Makefile
├── moat
│   └── util
│       ├── __init__.py
│       ├── times.py
│       └── _yaml.py
├── README.rst
├── setup.cfg
└── setup.py

OK. So when I run findimports on this, I get

$ PYTHONPATH=.:../util/ findimports --ignore-stdlib 
main.__init__:
  anyio
  asyncclick
  util
setup:
  setuptools

Now this is obviously suboptimal, as there's no "util" package and the toplevel isn't "main" either. I have to do

to get a more reasonable output of

moat.__init__:

moat.main.__init__:
  anyio
  asyncclick
  moat.util
setup:
  setuptools

To fix the requirement for the first touch statement I would like an option that tells findimports that it should assume that every dictionary it finds (or that's named on the command line) might be the root of a namespace package. This way the src/whatever style of laying out your source repository would still work unchanged.

Imported modules should be recognized no matter whether they're part of a namespace, i.e. the second touch should not be necessary even if I don't use that special new option.

mgedmin commented 2 years ago

Yes, currently findimports has no support for PEP 420 implicit namespace packages.

I don't know when (or if) I can find the desire/energy to work on this. Help (in the form of a pull request) would be greatly appreciated.