Quick abstract question: is there any way to make ...
# generala
astonishing-river-87155
02/22/2024, 9:51 PMQuick abstract question: is there any way to make pants start up + run faster when handling a small volume of data? E.g. I was thinking of making
pants tailorBUILDpre-commitastonishing-river-87155
02/22/2024, 9:52 PMIt looks like it's mostly starting pantsd and the scheduler and whatnot.
b
broad-processor-92400
02/22/2024, 9:55 PMyeah, pants relies on having the daemon/scheduler running to amortise the start-up cost. The theory would be that you pay this cost once, and then running commands is fast in future.
Are you finding its starting them every time? If so, do you set https://www.pantsbuild.org/2.19/reference/global-options#pantsd to false or https://www.pantsbuild.org/2.19/reference/global-options#concurrent to true?
a
astonishing-river-87155
02/22/2024, 9:55 PMTypically it's fast if you rerun it immediately after, but there's enough time between commits that folks typically have to pay the startup cost each time.
astonishing-river-87155
02/22/2024, 9:56 PMI have messed around with those options but it doesn't add that much speed.
I guess to avoid the X-Y problem: the overarching thing is just "how do I have a good UX for ensuring BUILD files are up to date?" I was just hoping to pull it before we fail someone's PR because of
pants tailor --checkb
broad-processor-92400
02/22/2024, 9:56 PMah okay, yeah, that's unfortunate
a
astonishing-river-87155
02/22/2024, 9:58 PMAnother thing I've thought of: running a process earlier on in the pre-commit hook that doesn't actually do anything with pants, but just starts the daemon + scheduler asynchronously. Then by the time we actually need to do work with it it'll be hot š
b
broad-processor-92400
02/22/2024, 10:00 PMAh, yeah, if you've got other work that can happen in parallel.
Some other ideas, none of which are great because they're change to workflow rather than just an optimisation to your existing one (tech change is easy, people change is hard š):
ā¢ use a pre-push hook instead of a pre-commit one, so that it's only paid when pushing, not for every commit
ā¢ put more critical parts of your developer workflow into pants so devs have to run it more often, and thus keep the daemon alive š
ā¢ in my work repo, we have an alias like the one below, and I have the habit of running
pants local Copy code
[cli.alias]
local = "tailor update-build-files fmt lint check ::"a
astonishing-river-87155
02/22/2024, 10:02 PMtech change is easy, people change is hard šI've never heard anything truer š
astonishing-river-87155
02/22/2024, 10:03 PMI've thought about (1) before but haven't really socialized it in my org. I'm going to talk through that w/ some more folks.
(2) and (3) we're not ready for yet, because we're still in the early stages of adoption. First target is just getting BUILD files to stay up to date + launching selective testing. But it will probably become better as time goes on b/c of continued use.
b
broad-processor-92400
02/22/2024, 10:04 PMah, yeah š
Ah, if you're in early stages, maybe another option:
ā¢ don't enforce in a pre-commit for now, but do check it in CI; key assumption: people won't often make changes that require updating BUILD files
a
astonishing-river-87155
02/22/2024, 10:06 PMYeah I'll do some PR analysis to see how many PRs actually touch a BUILD file
astonishing-river-87155
02/22/2024, 10:06 PMThank you for all of the pointers!
4 Views