# development


10/19/2022, 2:03 PM
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
. However I don't control the
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
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
CC @witty-crayon-22786 and @fast-nail-55400 who are immutable wizards 🧙‍♂️


10/19/2022, 4:05 PM
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 )
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