Multiple Build Targets

[jayceslesar]

Is it possible to specify multiple build targets, or is it better practice to have multiple pyproject.toml files? I basically have a use case where I want

[tool.hatch.buiild.targets.foo] with a custom configuration and similarly for a [tool.hatch.buiild.targets.bar], I want to have a different custom configuration.

[ofek]

Yes https://hatch.pypa.io/latest/cli/reference/#hatch-build

[jayceslesar]

Are there any documented examples of what this looks like in the wild?

[ofek]

Oh I see, you mean multiple custom targets. In that case you would create only the custom target and have different logic for each version. You would then build like hatch build -t custom:foo.

[jayceslesar]

Ah, thank you. Seems like I have opened a duplicate for #1669. Do I still need the get_builder? If I were to pass hatch build -t custom:foo how would I direct it to the foo builder, and similarly for the hatch build -t custom:bar if I had multiple BuilderInterface's defined?

[ofek]

You could define that yes but the main reason it exists is because sometimes you want to extend an existing builder which requires an import and then automatic detection does not work. I would recommend the version approach and only have a dedicated builder class. Currently there is no environment variable populated that indicates the current target & version so I don't think you would have a way to determine. That exists in a branch somewhere that I working on actually but I've been very busy.

[jayceslesar]

Ok, thank you so much, this was incredibly helpful! I will look into pushing some docs on this in the future if that is something you would find valuable.

One last question, how would I just inject custom build config into that callable that the get_version_api returns? I basically want to override the sources, include, and scripts and then build as normal using the hatch backend

[ofek]

For static config use TOML e.g. [tool.hatch.buiild.targets.custom.foo], for dynamic config use environment variables. The [tool.hatch.buiild.targets.custom] mapping is available as the property BuilderInterface.target_config.

[jayceslesar]

Maybe needs a new issue, but it doesnt look like force-include is respecting a custom target, anything past the custom key --> tool.hatch.build.targets.custom.foo.force-include seems to do nothing, but tool.hatch.build.targets.custom.force-include does

[jayceslesar]

Ah after looking at the source code it seems that the BuilderConfig does not respect a version at all, and instead the version is only used in the get_version_api, so any actual modifications would need to happen in an overridden build_standard function, because none of the BuilderConfig actually looks for the specified version in the pyproject.toml. Looks like version is entirely stripped in the cli as well https://github.com/pypa/hatch/blob/master/src/hatch/cli/build/__init__.py#L83.

Is modifying what happens in a build based on the version something you are interested in supporting? I would be happy to hack on that if possible, I am new to this project but it doesnt seem like a huge lift given the interfaces are so mature

[jayceslesar]

@ofek here is a working example of what I am attempting to accomplish -- note that versions are not respected with WheelBuilder, nor are the respective foo and bar versions with force-include entries in the pyproject.toml

https://github.com/jayceslesar/hatch-bug