Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

from a `--changed` perspective we can only operate at the target level.

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?

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.

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

yea. you'd actually have to create targets with dependencies to get that... ie, produce the frozen graph as BUILD targets.

interesting. what’s the general pants view on this? freezing deps isn’t important? just keep your pexes/other artifacts around somewhere?

<https://github.com/pantsbuild/pants/issues/6077>

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)

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?

unless you did something like `3rdparty/python/${module}/BUILD`

(which has the advantage of not needing to name the targets)

just ```$ cat 3rdparty/python/s3-log-parse/BUILD
python_requirement_library(
  requirements=[
    python_requirement('s3-log-parse==0.1.1')
  ]
)```

from a `pantsd` perspective, some amount of sub-file incrementalism is possible, because the resulting parsed structures will be identical.

question: is there ever going to be a "1.9.0 stable release"? I'm getting yelled at for using 1.9.0rc1 because it's "rc".

<@UBMAUCTQU>: yes, there will... there are two cherry picks inbound for 1.9.x, and then we'll cut rc2

...and then hopefully rapidly cut the final. cc <@U6ZRNH0TC>

it's my fault and i'm sorry and stu is correct

my goals today are to make the two cherrypicks and release 1.9.0rc2

i don't know what the expectation is for how long we wait after that to cut 1.9.0 itself, but i'll do whatever we normally do

"5 business days" ... <https://www.pantsbuild.org/release_strategy.html#stable-releases>

I see. so if rc2 is cut today then I can expect that 1.9.0 will be out around mid next week?

<@UBMAUCTQU>: er... speaking of which, the fix you submitted here: <https://github.com/pantsbuild/pants/pull/6331> has not been cherry-picked to 1.9.x

(i tested it pretty thoroughly in <https://github.com/pantsbuild/pants/pull/6339>, so i trust your fix)

<@U06A03HV1> we don't run into it very often either, so I wouldn't say it's super important if it's gonna mean some extra work.

if we weren't already cutting another rc, it'd be more work :smiley:

<@U6ZRNH0TC>: green! <https://github.com/pantsbuild/pants/pull/6278>

fyi, i put one other thing in `1.9.x` about 30 mins ago, so make sure you pull before picking.

Hey there! We’re experimenting with moving our large monolith from SBT -&gt; Pants. We’ve found some pretty compelling gains so far (compile times going from 30s -&gt; 4s, assembly times going from 5m -&gt; 30s) and so naturally we’re pretty excited.

One thing we’re struggling with however is our dependency management. We have a number of transitive dependencies where we need to exclude particular class paths.

I’m trying to follow a similar pattern under “controlling JAR dependency versions” here: <https://www.pantsbuild.org/3rdparty_jvm.html>. It seems that any exclusion included applied to the entire build and not just that library.