https://pantsbuild.org/ logo
e

echoing-manchester-70122

06/02/2020, 11:46 PM
why is pants deleting content from my init.py files?
Copy code
$ wc -l __init__.py
     125 
$ wc -l /Users/amckenna/code/python-commons/.pants.d/pyprep/path/to/__init__.py
       0
w

witty-crayon-22786

06/02/2020, 11:49 PM
it’s likely creating empty ones in places where none existed in targets
e

echoing-manchester-70122

06/02/2020, 11:49 PM
but one does exist
w

witty-crayon-22786

06/02/2020, 11:49 PM
do you have targets that own those
__init__.py
files?
e

echoing-manchester-70122

06/02/2020, 11:49 PM
yes
w

witty-crayon-22786

06/02/2020, 11:50 PM
and they show up in
./pants filedeps
for the thing you are running?
e

echoing-manchester-70122

06/02/2020, 11:50 PM
rglobs('*.py') should get init.py files right?
w

witty-crayon-22786

06/02/2020, 11:50 PM
yea, it should. but good to confirm that you see it in filedeps
if you do, it’s probably worth filing a bug there describing what you’re seeing, and mentioning which version you’re on
e

echoing-manchester-70122

06/02/2020, 11:56 PM
do builds not include submodules by default or something?
If I add a BUILD file in the subdirectory suddenly everything works
w

witty-crayon-22786

06/02/2020, 11:57 PM
hm
pants does not have any particular logic for git submodules…
e

echoing-manchester-70122

06/02/2020, 11:58 PM
it's not a submodule
I'm talking about python modules
w

witty-crayon-22786

06/02/2020, 11:58 PM
mm
so, no, “modules below some module” in a hierarchy are not included by default… only target dependencies or globs would pull something in
e

echoing-manchester-70122

06/02/2020, 11:59 PM
rglobs doesn't pull in subdirectories?
w

witty-crayon-22786

06/02/2020, 11:59 PM
rglobs should be sufficient to do the latter thing
e

echoing-manchester-70122

06/02/2020, 11:59 PM
I thought that was the difference between globs and rglobs
w

witty-crayon-22786

06/02/2020, 11:59 PM
it does.
did you confirm that you weren’t seeing it in filedeps?
e

echoing-manchester-70122

06/02/2020, 11:59 PM
it's there in filedeps
w

witty-crayon-22786

06/03/2020, 12:00 AM
both before and after adding the BUILD file…?
e

echoing-manchester-70122

06/03/2020, 12:00 AM
definitely before
w

witty-crayon-22786

06/03/2020, 12:00 AM
that’s very odd. that would just be a bug, i think.
possibly related to how we try to inject init files in cases where they don’t already exist
a repro would be really appreciated in a ticket. we’ve been discussing adding/adjusting magic there.
sorry for the trouble.
e

echoing-manchester-70122

06/03/2020, 12:01 AM
ok thanks
h

hundreds-father-404

06/03/2020, 12:02 AM
Including which Pants version and if this is using the V1 execution engine or V2. The code paths are different between them
e

echoing-manchester-70122

06/03/2020, 12:02 AM
0.23, on v1 afaik
it seems like tests and module files are being put in the same directory for testing?
is this correct?
w

witty-crayon-22786

06/03/2020, 12:23 AM
if they are in the same module, yea.
e

echoing-manchester-70122

06/03/2020, 12:23 AM
ok well then I'm guessing the init from the test directory is overwriting the other one
w

witty-crayon-22786

06/03/2020, 12:23 AM
mm. yuck. yea.
in v2 that will result in an error iff they don’t have identical content.
e

echoing-manchester-70122

06/03/2020, 12:26 AM
removing the blank init files from the test dirs solves the problem
🙌 2
h

happy-kitchen-89482

06/03/2020, 1:27 AM
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.
If this worked before now it's presumably because the "good" file happened to be picked.
But possibly we should warn about this when we merge the chroot.
w

witty-crayon-22786

06/03/2020, 1:59 AM
yea, v2 will/does.
5 Views