https://pantsbuild.org/ logo
Join Slack
Powered by
I have a need for a plugin to codegenerate (really...
# development
b
I have a need for a plugin to codegenerate (really download) large files as "resources" (system libraries). They're fully versioned and hashed, and can be large. That makes them prime candidates for 
immutable_inputs
. However I don't control the 
immutable_inputs
for 
run
and 
test
goals for relevant consumers. I'm thinking we might want a new union for this exact thing. Instead of "codegen" it'd be (bikeshed naming) "immutable_input_gen", and the impl is pretty much like existing art, minus the 
protocol_source
maybe (which is meaningless). Existing codegen would be wired to consider this as well, and goals need to handle accordingly after hydrating dependencies. (very slightly related to https://github.com/pantsbuild/pants/issues/16707)
CC @witty-crayon-22786 and @fast-nail-55400 who are immutable wizards 🧙‍♂️
w
hm. i think that immutable inputs are sortof an implementation detail… but in a positive way:
i think that over time, we’ll want many things to be implemented via symlinks (see https://github.com/pantsbuild/pants/issues/14070#issuecomment-1227645527 )
and exposing it to the user API makes it slightly more manual then that.
so one question i have is: are there any heuristics that would work for this case, so that you don’t need to do this explicitly? or, should the part that is explicit be more like a hint/forcing of the heuristic rather than an explicit target type?
one strawheuristic would be to symlink all files above a certain size by default, and have processes need to opt out of that if they need to be able to mutate things
…yea, honestly: i think that that would likely work fairly well. requires making some already-designed changes to immutable_inputs to make it “includelist based” rather than being a hashmap of digests, but after that would require no external API
can sketch that out later today if it would be helpful.
❤️ 1
Open in Slack
PreviousNext
Powered by