New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Speed up run
to no longer rebuild a Pex on source file changes
#10410
Conversation
[ci skip-rust-tests]
[ci skip-rust-tests]
class RunRequest: | ||
digest: Digest | ||
binary_name: str | ||
extra_args: Tuple[str, ...] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: "extra" to me tends to imply that things are added afterward. Maybe prefix_args
?
async def run_python_binary( | ||
field_set: PythonBinaryFieldSet, python_binary_defaults: PythonBinaryDefaults | ||
) -> RunRequest: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels like rather than being binary (or repl) specific, this is connected to TwoStepPex
... where rather than creating two pexes (one for requirements, the other for sources, iirc) we instead could use a requirements pex, and a Digest
of loose sources.
Repl
already uses TwoStepPex
, so perhaps starting there would make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. We use TwoStepPex
for binary
and awslambda
, actually. TwoStepPex
results in one single Pex file. I think it's important that it continues to behave the same way.
I plan to change repl
tomorrow to behave the same way as run
. If it helps, I can bundle it into this PR. Only wanted to get this one up as a checkpoint and to make it in time for the release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so. We use TwoStepPex for binary and awslambda, actually. TwoStepPex results in one single Pex file. I think it's important that it continues to behave the same way.
Got it: my mistake.
I plan to change repl tomorrow to behave the same way as run. If it helps, I can bundle it into this PR. Only wanted to get this one up as a checkpoint and to make it in time for the release.
No need to bundle. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No mistake - it was a good question! I was wondering around the same time you wrote the original question "Hm, can we delete TwoStepPex now?"
I would maybe edit the title slightly - it's not that we no longer invalidate on source file changes (that would be broken), it's that we no longer rebuild a pex... |
run
to no longer invalidate on source file changesrun
to no longer rebuild a Pex on source file changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
|
||
|
||
@rule | ||
async def run_python_binary( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: this doesn't actually run the binary: just produces it.
FYI that according to git bisect this broke /pants run build-support/bin/generate_docs.py, because it can no longer see its resources. |
The resources are in the chroot, so maybe some PYTHONPATH issue. |
OK, the problem is that loading relative to |
I think this is a quirk of the loader system in python, possibly not something we should address here. |
Workaround is to use |
Hm, does that workaround work still if you run |
It does work in that case. |
It looks like one other visible effect of this change is that there won't be a |
That expects PEX-INFO during |
It's less that they "expect it during run", and more that they expected the |
Hm, okay. Yeah, I'm thinking about a new user who has never used Pants or Pex. I think they would expect this current implementation. You don't normally need a Pex to run a script, so why would you need it here? Whereas with |
Whereas
binary
must include source files in the PEX,run
does not need to. We get less cache invalidation and generally faster performance by instead having the chroot simply be populated with the source files, similar to how we implement Pytest.We still use a Pex to handle the
entry_point
field and to resolve all 3rd party requirements.Before, with a whitespace change:
After, with a whitespace change:
Implements half of #10406.