-
-
Notifications
You must be signed in to change notification settings - Fork 641
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
Mainline pants has a slow development cycle #21096
Comments
I've made suggestions in the slack chat, but essentially, I'm curious if we can kick any of that to |
I agree, or in general, some way to fully lazy-load backends - so unless your selected target requires the backend - it's basically ignored. But, chicken and egg, without loading the backend, how can you identify target types |
We've talked previously about using Pants to build Pants ("bootstrapping"): This might help solve this problem, in some ways, by dramatically reducing how often the scheduler is invalidated and restarted. Editing the Python backend for the Pants-in-repository doesn't require restarting the orchestrating-Pants scheduler, because orchestrating-Pants is using its own backend. (e.g. if this repo is configured to use The work on the new |
I'd be a huge fan of treating pants like a pants repo. And I think Stu's suggestion of having a "binary engine mode" against a "source engine mode" would make sense as the degenerate case. I mean, in-repo plugins can kinda do that already using |
Pulled from the associated slack chat.
Two problems I run into are:
coursier
runs and starts downloading a bunch of stuff - even though I've never touched our java/jvm/scala/kotlin codeAs an example of the 2nd.
After fixing a typo in a function comment, and formatting, I spend 31 seconds waiting for that to finish.
In some more egregious cases, I've waiting up to 60 seconds for a fmt/lint to run, and most of the time happens in the "scheduler" (handwaving everything before running the goal as "scheduler").
I narrowed the bulk of the time spent to commenting out
#"internal_plugins.test_lockfile_fixtures",
in thepants.toml
- and then went further with removing the JVM entirely.The following diff brought my cycle time down to closer to 6-7 seconds (which I think can be even better). My integration tests also run about 1 second faster, for the 1 test I run.
My git diff
The text was updated successfully, but these errors were encountered: