https://pantsbuild.org/ logo
Join Slack
Powered by
<@U051221NF> Do you have any thoughts on this?
# development
p
@happy-kitchen-89482 Do you have any thoughts on this?
h
Re pantsd: it exists not just because of build graph creation time (which is orders of magnitude faster now with call-by-name) but because it memoizes rule executions, and it watches the filesytem. Those are important for fast iterative builds.
Even if engine start time was instantaneous, you would have to rescan the filesystem and re-execute a lot of work every time
@powerful-scooter-95162 what is your specific need here? concurrent invocations of pants, or concurrent execution of goals in a single pants run?
p
concurrent pants invocations is the main one. Hopefully faster than pants_concurrent. Though running check & test in parallel would be great too.
though I guess I care less about check & test since we migrated from mypy to ty
w
since we migrated from mypy to ty
Are you using my plugin for that? Or did you make a new one
p
We had claude write one. We ran into issues with yours and claude came up with a super hacky fix that I don't think anyone would want
w
Ah, I'd like to mainline the one i have, once I fix some issues - but in spite of what they said, I still feel Ty needs a bit more seasoning. I ran into some random issues in some of my repos, which might now be fixed - so I'd need to revisit
p
We were very unhappy with mypy, so ty feels like a big upgrade
💯 1
w
Yeah, for me, it was much faster, but much wronger... But, that was like... 2 days after it "released" - so I don't hold that against them 😄 Anyways, was just curious
f
Re my PR for releasing the concurrency lock, it is definitely hacky. It really would work well for actions in a "tail call"-like position in the Pants rule logic where no other rule logic will run for the goal. And running a process for the 
run
goal is just such a position.
p
Can we check in tdyas' approach? Or is there a better way forward here? I feel like tail call actions are the things that hold the lock for the longest
h
I don't think we can simply merge the current PR as-is, the concurrency questions are not something we can handwave away. How far does "releasing the lock before entering the final `run`" get you towards solving your immediate need?
p
"releasing the lock before entering the final `run`" seems perfect
is run here meaningfully different from check & test ?
h
Not necessarily, I think we could have any goal say "this is my final process run, and its result is the overall goal result"
p
that would be really great if this was a simple fix
f
I tried formulating the change as "any goal say 'this is my final process run, and its result is the overall goal result'" but that would require some rethinking about the return type from goals in my view.
and I wanted to avoid changing the semantics of the plugin API in that deep of a manner
the change would be "better" from a design standpoint if a goal rule could return a 
Process
to run after the goal rule logic ends instead of an exit code (in whatever dataclass is used for that purpose, brain is not recalling the name at the moment)
This would fit more closely with the "tail call" aspect of running the 
Process
h
Oh it will not be a simple fix...
But simplER perhaps than completely eliminating the lock
Open in Slack
PreviousNext
Powered by