What is the distinction between a `files()` target...
# general
h
What is the distinction between a
files()
target and a
resources()
target?
h
We don’t strip the source root of files(). You should use files() when using file system operations like
with open()
if you want to pass the whole path relative to the build root
h
đź‘Ť
w
and resources are treated as platform level resources, loaded with either the JVM or python APIs for that
while files are basically just extracted into the test sandbox
a
if you have, say, a
python_binary
that depends on
files
, are the files included in the PEX? or is that only if they're
resources
?
h
Yes, they are included in the PEX and we won’t strip any source roots. Normally, we strip src/python/f1.py to simply f1.py. We don’t do that for
files
w
Hm... is that accurate? How would you use un-namespaced loose files inside a pex?
An issue with that would be that it is not uniform between tests and prod:
resources
are loaded the same way from a test vs in prod
On the other hand, a bundle might be something where we could recommend
files
(assuming some more investment)
h
Hm... is that accurate?
I believe so. We strip source roots for every target type except for
files()
. If you use
resources()
, for example, then we convert
src/python/f1.txt
into
f1.txt
. In Pants’ tests, this is how we get it working to be able to copy over the entire directory
testsprojects/src/python/.../example
and then open that exact path in the test via
with open()
, rather than having to think about what the path would be if we stripped
testprojects/src/python
w
tests vs binaries are a different story here, i think
important distinction
because when we run the test, we put loose files in the workspace and you can use them using
open
relative to your cwd and etc
but in prod, if we "put them in the pex", they would no longer be loose, and would need to loaded some other way
for "loose" files deployed to prod, we have traditionally recommended bundles, which are a zip file of loose stuff next to a pex
the
files
target is relatively new, and not at all integrated with
bundles
/
*_app
(a much older concept) although they probably should be.
h
Huh, TIL
h
I think they do get bundled into the pex, but you'd have to jump through hoops to get at them (e.g., run with zip_safe=False and do some magic with
__file__
to find them relative to yourself).