Dependency inference issue I encountered. suppose there’s a library

lib

, with 3 files •

lib/__init__.py

•

lib/a.py

•

lib/b.py

And

__init__.py

imports

b

and some other binary imports

a

directly. When packaging the binary it fails to package both

__init__.py

and

b.py

I’m using pants 2.7.1 Is there a way to help the inference? or should I just specify files manually?

See "Do you have content in your

__init__.py

files?"https://www.pantsbuild.org/docs/python-backend

Why not enable this by default?

Good question - @hundreds-father-404 why isn't inferring ancestor

__init__.py

deps on by default?

Because when we added this feature in Pants 2.0, we were heavily weighting v1 users who weren't yet using dependency inference Some background: when you declare

python_sources

in a BUILD file (called

python_library

before Pants 2.8), that generates one

python_source

target per file in the

sources

field. Those generated targets inherit all the metadata you set in the

python_sources

. So, if you have this:

python_sources(
    dependencies=["dep1", "dep2", "dep3"],
)

The

python_source

target generated for

__init__.py

will have all three of those deps, even though it might not actually use them. Then, when you combine with

__init__.py

inference, this means that everything located recursively under that

__init__.py

will transitively depend on those 3 deps. You end up depending on way more than you actually wanted -- That is much less of a concern in a world where you use dependency inference, and particularly because we now have the

overrides

mechanism https://www.pantsbuild.org/v2.8/docs/reference-python_sources#codeoverridescode It's now feasible for us to switch the default. Although we have to do that with a deprecation. Thoughts?