Ok, so I've almost got my PoC going. Last bit is I...
# development
b
Ok, so I've almost got my PoC going. Last bit is I want to get the fingerprint of a Process for a
shell_command
. But not necessarily run it. 🤔
This is in the context of engine compilation. I want to hack a way to shortcut the engine compilation. We could use the hand rolled metadata file. But the cache key for the compilation process would be golden
So we'd dump the fingerprint of the compilation process in a file and THAT becomes the metadata file. Then as a speed hack, we can copy the metadata file and engine from scie-pants' running Pants and if they match we bypass running compilation
b
Sounds like https://github.com/pantsbuild/pants/issues/8445 https://github.com/pantsbuild/pants/pull/18383, I think, means one could hash the output of
peek
+ some other bits to achieve this.
b
Hmm so ideally this is within Pants, like a target. But seeding it manually could work as well. We have options, especially since we control scie-pants delegation in our repo, and because all of this is for a speed hack
b
yeah, totally. On a completely different note, I wonder how we can assess the impact that the speed hack might have in the real world before implementing, to see if it's worth the effort.
b
On my turbo computer it takes a minimum 3 minutes when I fast forward main past an engine change. I can't imagine it for a laptop 😬
b
I guess I'm thinking seeing how often the speed-hack will actually do anything useful (e.g. hashes match) based on our commits in practice
(btw, do you know about setting
MODE=debug ./pants ...
to do debug builds rather than release for local dev. https://github.com/pantsbuild/pants/pull/18838)
b
That should be calculable
👍 1
And yeah, I don't use MODE==debug because I've seen that the savings in compilation lead to much longer startup time. And in my dev cycle I restart more than recompile
w
And yeah, I don’t use MODE==debug because I’ve seen that the savings in compilation lead to much longer startup time. And in my dev cycle I restart more than recompile
i think that i fixed that in https://github.com/pantsbuild/pants/pull/18838, so do give it another try.
as to “hash of a target”, the challenge has always been that the thing that actually matters is “hash of some particular process that produces an artifact i care about”, rather than of any particular target itself.
➕ 1
a
shell_command
might unambiguously have such a thing, but a
python_sources
target does not
➕ 1
b
Yeah, best avoid the question I suppose. Even code-generating targets don't have a 1:1 equivalent. I have codegen targets that just create the output in the rule itself