@curved-television-6568 Hitting an issue in this function with my target generator that generates multiple different target types, because I haven't set an alias. What's this doing exactly?

First, the

alias

is "required", so not providing one will break assumptions about it being present: https://github.com/pantsbuild/pants/blob/ec86d19cd954cd49a9562880a7c0dbc45632778c/src/python/pants/engine/target.py#L255-L256 I think you can get away with an empty string as value rather than leaving it out (not sure, though.) preferably you pick some internal looking name, as it will show up in error messages etc, and not having a legible value could be confusing then. (pants use a single underscore prefix for such targets.) Now to what's actually going on on that line, it is fetching any

__defaults__

that should apply to the targets being generated. That is, say you make your own target generator that generates

python_source

targets.. if you have

__defaults__({python_source: dict(tags=["foo"])})

you'd expect those generated targets to be tagged with

"foo"

, right? 🙂

Any opposition to me creating a feature request to support this / are you aware of any other potentially problematic areas to get this fully supported? I have some time to hack away at this this morning and this weekend.

oh, what I meant was just to charge ahead, set the alias and it should work (besides the defaults, do you mean to support defaults for target generators producing multiple types?)

Additional additional context: as of right now the actual generated dbt targets are pretty much just a source field, dependencies, and common target fields but we'll probably also want skip linting / formatting fields for specific types like macros (famously hard to lint).