from a `--changed` perspective we can only operate...
# general
w
from a
--changed
perspective we can only operate at the target level.
f
right, but this is a case where multiple targets all use the same requirements.txt as input. does any change at all to requirements.txt cause all targets depending on it to change?
w
Yes.
What that should have said is "file/target" level
afaik though, there isn't really a good reason to use a
requirements.txt
file once your repo grows beyond a certain size
can just use individual requirements targets, which dodges that issue.
. @rough-minister-58256 may know better though.
f
is there a nice way to get a frozen list of all transitive dependencies w/o using a requirements.txt? or just some other way of ensuring that full closure of external dep versions are frozen at a particular commit?
actually… I guess it just dawned on me that having all your frozen requirements in a requirements.txt probably doesn’t actually make pants respect any of the dependencies there. like, I’m guessing pants isn’t querying pypi to take the dep graph of libs and mirror it in pants’ dep graph
w
yea. you'd actually have to create targets with dependencies to get that... ie, produce the frozen graph as BUILD targets.
f
interesting. what’s the general pants view on this? freezing deps isn’t important? just keep your pexes/other artifacts around somewhere?
w
as that says, twitter works with the "frozen snapshot of wheels" strategy currently, since the other bit about 1) is that it lets you include whls in all cases rather than ever building something
but i think that 2) could likely work fairly well (even without any changes to pex)
both approaches require tooling
f
oh, sorry one more thing, but about the original point of not using a requirements.txt so that the change system won’t think everything changes when you change a repo; AIUI changes to a BUILD file also just invalidate anything defined in that BUILD file (at least in 1.7 this seems to be the case), so you’d still run into this issue if you kept all your
python_requirement
targets in the same 3rdparty/python/BUILD file, right?
w
unless you did something like
3rdparty/python/${module}/BUILD
(which has the advantage of not needing to name the targets)
just
Copy code
$ cat 3rdparty/python/s3-log-parse/BUILD
python_requirement_library(
  requirements=[
    python_requirement('s3-log-parse==0.1.1')
  ]
)