Building variant wheels from same source code

[sponsfreixes]

Is there a way of building two different Python wheels from the same source code, with one of the wheels not including some specific module/package?

I could use two different pyproject.toml files, but it seems that hatch build doesn't accept the --config option.

I looked at the documentation for environments and versions, but if they are the solution, I can't figure out how to use them for my scenario.

Thanks!

[teruokun]

It would be good to understand your use-case in a bit more detail to understand why the following options aren't good choices:

• Using standard extras metadata to define an added named feature set which requires additional dependencies
• Conditional dependencies which are based on platform, python version, or the version of another dependency

[sponsfreixes]

Sure, let me explain better the use case, I didn't do a good job on the initial post.

I work on a company that wants to create a Python library. This library will be distributed in two ways:

• Internally, using a devpi repository that only company workers can access. The plan is to create a wheel with all the features of the library, and push it to the devpi repo.
• We want to share that same library with some customers. We will share with them the wheel file (copying it to some artifact repository), and they can manually download and install it. The catch is that we want them to only access a subset of the functionality.

I can create these two wheels by building first with:

[tool.hatch.build.targets.wheel]
packages = ["src/my-library"]

And then building again after changing it to:

[tool.hatch.build.targets.wheel]
packages = ["src/my-library"]
exclude = ["src/my-library/extra-features"]

I'm currently doing it manually, but once we put that on a CI, it becomes awkward to automate. I would be OK with having two different pyproject.toml files, but it seems that hatch build doesn't accept the --config option.

I know that an option would be to put the extra functionality on a separate package, but then we have to tell our internal users to either do pip install my-library my-library-extra-features or pip install my-library[extra-features], and it's not as nice as just pip install my-library, plus the fact than now we have two separate code bases.

[ofek]

That makes more sense, thanks for triaging this Jeff!

What you could do is create a custom build target and invoke hatch build -t custom. The file would look basically like:

from hatchling.builders.hooks.plugin.interface import BuildHookInterface
from hatchling.builders.wheel import WheelBuilder

def get_builder():
    return CustomWheelBuilder

class CustomWheelBuilder(WheelBuilder):
    pass

[teruokun]

That description makes a lot of sense and the custom build target does sound about right overall, and expanding on the solution Ofel provided, what it’s doing is giving you a separate configuration space with the existing wheel builder so that you can configure it independently from your standard wheel config in your existing pyproject.toml. If there’s a feature request embedded here, it might be the ability to easily reuse an existing builder implementation with alternate configuration name. Something akin to : [tool.hatch.targets.limited_wheel] builder=“wheel” # or maybe template if it should inherit the other config by default too exclude=[“<myinternal-stuff>”] But I’ll defer to Ofek since I don’t know how much it would complicate internals and the existing suggestion would definitely work

…

On Fri, Aug 9, 2024 at 1:52 PM Ofek Lev ***@***.***> wrote: That makes more sense, thanks for triaging this Jeff! What you could do is create a custom build target <https://hatch.pypa.io/latest/plugins/builder/custom/> and invoke hatch build -t custom. The file would look basically like: from hatchling.builders.hooks.plugin.interface import BuildHookInterfacefrom hatchling.builders.wheel import WheelBuilder def get_builder(): return CustomWheelBuilder class CustomWheelBuilder(WheelBuilder): pass — Reply to this email directly, view it on GitHub <#1669 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYCRPIGZAF7B4VFVYVC5ZDZQUTYLAVCNFSM6AAAAABMFLYKSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZYG42DANRTGI> . You are receiving this because you commented.Message ID: ***@***.***>

[ovidiu-eremia]

Hi @ofek @teruokun,

Sorry for bothering you here, but I have a similar situation in a monorepo:
#1676

Could you please take a look? I would just need an advice on how to best implement the builder plugin to do such a thing...

Thank you!