Hi, I'm taking a whack at https://github.com/pantsbuild/pants/issues/13589 and it's beginning to feel like the wrong approach. In the issue one of the suggestions is to "avoid a proliferation of targets" which makes sense, but this really feels like it should be a separate item with:

download_file(name:str, description:Optional[str], url:str, expected_digest:str, expected_size:Optional[str], path:str)

That will then materialize the file to be used afterwards in any

file(s)

or

resource(s)

targets after the fact. Overloading

file

and

resource

with optional URL/digest/etc options feels more confusing than helpful

At that point you've waded into codegen. Effectively this would act as codegen, not from a proto file, but from some configuration data in a BUILD file (url, fingerprint, size, output path). That sounds sane to me, but I'm not sure whether or not this can be done yet. There is active work surrounding target generation and this is also eariler in the typical lifecycle for injection of "things" into the normal rule flow - there may or may not be bumps there. Stu and Tom have been active in this space recently, but it may be best to keep the discussion on the ticket going instead of fracturing it.

thanks, will do done, comment at https://github.com/pantsbuild/pants/issues/13589#issuecomment-1043148174

I’m not sure whether or not this can be done yet. There is active work surrounding target generation

I don’t think there is need for target generation here. Only support for

file

and

resource

targets to be able to consume the generated sources of

download_file

.

Yeah, I was off there. Just code gen no target gen involved here.