why is pants deleting content from my init py files

Question

echoing-manchester-70122 · Answer

```$ wc l init py 125 $ wc l Users amckenna code python commons pants d pyprep path to init py 0```

witty-crayon-22786 · Answer

it s likely creating empty ones in places where none existed in targets

echoing-manchester-70122 · Answer

but one does exist

witty-crayon-22786 · Answer

do you have targets that own those ` init py` files

echoing-manchester-70122 · Answer

yes

witty-crayon-22786 · Answer

and they show up in ` pants filedeps` for the thing you are running

echoing-manchester-70122 · Answer

rglobs py should get init py files right

witty-crayon-22786 · Answer

yea it should but good to confirm that you see it in filedeps

witty-crayon-22786 · Answer

if you do it s probably worth filing a bug there describing what you re seeing and mentioning which version you re on

echoing-manchester-70122 · Answer

do builds not include submodules by default or something

echoing-manchester-70122 · Answer

If I add a BUILD file in the subdirectory suddenly everything works

witty-crayon-22786 · Answer

hm

witty-crayon-22786 · Answer

pants does not have any particular logic for git submodules

echoing-manchester-70122 · Answer

it s not a submodule

echoing-manchester-70122 · Answer

I m talking about python modules

witty-crayon-22786 · Answer

mm

witty-crayon-22786 · Answer

so no modules below some module in a hierarchy are not included by default only target dependencies or globs would pull something in

echoing-manchester-70122 · Answer

rglobs doesn t pull in subdirectories

witty-crayon-22786 · Answer

rglobs should be sufficient to do the latter thing

echoing-manchester-70122 · Answer

I thought that was the difference between globs and rglobs

witty-crayon-22786 · Answer

it does

witty-crayon-22786 · Answer

did you confirm that you weren t seeing it in filedeps

echoing-manchester-70122 · Answer

it s there in filedeps

witty-crayon-22786 · Answer

both before and after adding the BUILD file

echoing-manchester-70122 · Answer

definitely before

witty-crayon-22786 · Answer

that s very odd that would just be a bug i think

witty-crayon-22786 · Answer

possibly related to how we try to inject init files in cases where they don t already exist

witty-crayon-22786 · Answer

a repro would be really appreciated in a ticket we ve been discussing adding adjusting magic there

witty-crayon-22786 · Answer

sorry for the trouble

echoing-manchester-70122 · Answer

ok thanks

hundreds-father-404 · Answer

Including which Pants version and if this is using the V1 execution engine or V2 The code paths are different between them

echoing-manchester-70122 · Answer

0 23 on v1 afaik

echoing-manchester-70122 · Answer

it seems like tests and module files are being put in the same directory for testing

echoing-manchester-70122 · Answer

is this correct

witty-crayon-22786 · Answer

if they are in the same module yea

echoing-manchester-70122 · Answer

ok well then I m guessing the init from the test directory is overwriting the other one

witty-crayon-22786 · Answer

mm yuck yea

witty-crayon-22786 · Answer

in v2 that will result in an error iff they don t have identical content

echoing-manchester-70122 · Answer

removing the blank init files from the test dirs solves the problem

happy-kitchen-89482 · Answer

Ah yes To clarify this reflects a real world Python problem that isn t unique to Pants If you have two colliding modules in different source roots that one will necessarily shadow the other it s just how importing works

happy-kitchen-89482 · Answer

If this worked before now it s presumably because the good file happened to be picked

happy-kitchen-89482 · Answer

But possibly we should warn about this when we merge the chroot

witty-crayon-22786 · Answer

yea v2 will does