bitter-ability-3219004/11/2022, 1:45 PM
. Ideally, at any point where something depends on this module, it would get inferred. I think that's possible if I code it so the target is a code generator (because it kind of is). This kind of ignores a lot of hermeticity, but oh well. The two problems I face are
. (I think I can wire up the codegenerator to invoke
much like the
.) It's actually very trivial to add a
plus plumbing to Pants (and I want to upstream that). But the problem is that the existing machinery we'd want to re-use for building the sandbox filters the transitive dependencies to be "sources that likely make sense". Since
, I'll silently get nothing showing up in the sandbox. This smells of a larger problem though. Pants has tons of machinery revolving things with a "source". Codegen, generator targets, etc... But unless your chain of targets/rules/fields starts with a sources field, you don't get to participate (and in this case, my target gets silently filtered). One issue is that a dependency is just a target address, and so you need to know how to get it onto disk. If there was a way to take any target and ask make a request which gets it onto disk then you can have anything depend on anything.
and omit • Declare a generator which generates a
• Provide a rule which downloads the file and produces a
This is however, an abuse of the system IMO.
witty-crayon-2278604/11/2022, 6:30 PM
bitter-ability-3219004/11/2022, 6:47 PM
) and runtime dependencies. But I suppose for
everything is a build-time dep. And the runtime deps is all calculated install-side by installing the wheel.