Wheel tags

[henryiii]

Is there a way to control the wheel tags? I was just suggesting to someone to use build, and found they needed python3 setup.py bdist_wheel --python-tag py39 to build wheels, since the package depends on building the unicode tables in each Python version to make a wheel. Is there a way to pass this through or set it? It could be something simple in setuptools, like universal=1 was, but I realize I don't know what it would be. I tried pyproject-build --config-setting "--python-tag py39" (yes, off my pipx install ;) ), but that didn't fail or do anything different, just produced the normal py3 wheel.

[di]

In theory --config-setting should work but backends like setuptools do not support it yet: pypa/setuptools#2491

[FFY00]

PEP517 has an interface to pass extra settings to backends, it's called config_settings. It allows us to pass a dictionary to the build backend with extra information.
https://www.python.org/dev/peps/pep-0517/#config-settings

As Dustin mentioned, we do already support it via the --config-setting/-C argument. The format is -C key=value.

For eg., python -m build -C my_setting=true -C some_value=9 -C something=someting will result in the following dictionary:

{
    'my_setting': 'true',
    'some_value': '9',
    'something': 'something',
}

It's up to the build backends, in this case setuptools, to support passing configuration options this way.

[FFY00]

There are some limitations with this, it only maps keys to strings. I wanted to wait for backends to start using this to see what kind of interface would make sense to use here.

[layday]

setuptools supports only one configuration setting: --global-option. I suppose this was intended to mirror pip wheel. You can build a wheel for Python 3.9, rather unintuitively, like this: pyproject-build --wheel -C="--global-option=--python-tag" -C="--global-option=py39".

[FFY00]

Uh, I think python -m build -C--global-option=--python-tag=py39 would work here then.

[layday]

It needs to be split up so that build will parse it into a list and --wheel is required because --python-tag is not valid for sdists. (But yes, the equals sign and the quotes are superfluous.)

[FFY00]

Ah, right. Perhaps setuptools could help here by treating a string as a single element list.

I think -C--global-option= -C--global-option=--python-tag=py39 would also work but I am not sure how much better that would be.

[henryiii]

• python -m build -w -C--global-option=--python-tag=py39 doesn't work
• python -m build -w -C--global-option= -C--global-option=--python-tag=py39 doesn't work, but makes it further
• python -m build -w -C="--global-option=--python-tag" -C="--global-option=py39" Works!

[henryiii]

It really should be the build backend that has a setting that says "python version specific / OS specific / arch specific", I'd think. But that workaround does work, thanks!

[henryiii]

I think this is resolved, as far as build is concerned, you can close unless there's anything to be done.

[vEpiphyte]

@henryiii FYI with the changes from #627 the examples here no longer seem to work.

[henryiii]

There should be similar (working) examples in the docs. Is there anything specifically that's missing?

[vEpiphyte]

I'm not certain what is missing per say, since I do not see any end to end examples in the docs on https://pypa-build.readthedocs.io/en/stable/index.html

Using the global-option flag generates a setuptools warning:

        ********************************************************************************
        The arguments ['--python-tag', 'py39'] were given via `--global-option`.
        Please use `--build-option` instead,
        `--global-option` is reserved for flags like `--verbose` or `--quiet`.

        By 2023-Sep-26, you need to update your project and remove deprecated calls
        or your builds will no longer be supported.
        ********************************************************************************

To avoid this warning, I was previously using $ python -m build --wheel "-C=--build-option=--python-tag py311" with 0.10.0 to build a wheel with a specific tag. This now generates the following error with build 1.0.0 :

$ python -m build --wheel "-C=--build-option=--python-tag py311"
_build config_settings={'--build-option': '--python-tag py311'}
* Creating venv isolated environment...
* Installing packages in isolated environment... (setuptools>=68.0.0, wheel)
* Getting build dependencies for wheel...
usage: _in_process.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: _in_process.py --help [cmd1 cmd2 ...]
   or: _in_process.py --help-commands
   or: _in_process.py cmd --help

error: option --python-tag not recognized

ERROR Backend subprocess exited when trying to invoke get_requires_for_build_wheel

I'm not 100% certain if this is a case of holding the tool wrong, or if there is some aspect of the changelog entry related to #627 that I do not understand properly. Bisecting the build repo shows the build failing when that PR was merged.

[henryiii]

Ahh, I got this confused for a different issue in a completely different repo (wheel). Do you have a repo I could test? I’ll look at it very soon.

The correct way to work around this setuptools bug is in #264 (comment), have you tried that?

[vEpiphyte]

For reference, the repo I am working with is here https://github.com/vertexproject/synapse but I imagine it would be a pretty generic issue. I will review that thread you linked and try it.

[abravalheri]

Probably related to pypa/setuptools#3896 (which is a pending "FR" that still needs desgin+implementation)

For the time being, it is not possible to pass config_settings for a specific part of setuptools or plugin (in this case, the plugin implemented in pypa/wheel, bdist_wheel ), without passing it to all other parts (E.g. sdist, dist_info, ...).

The error happens because only bdist_wheel knows how to handle --python-tag, but the other parts don't.

For the time being, the safe way to do that is to have a setup.cfg file with:

[bdist_wheel]
python_tag = py39

You can also use a trick like:

export DIST_EXTRA_CONFIG=...  # e.g. /tmp/build-opts.cfg
echo -e "[bdist_wheel]\npython_tag=py39" > $DIST_EXTRA_CONFIG

But there might be tools (maybe cibuildwheel if I am not wrong) that depend on DIST_EXTRA_CONFIG for other purposes in some platforms and might end up overwriting it...

[layday]

The correct way to work around this setuptools bug is in #264 (comment), have you tried that?

"Correct" might be stretching it 😛

[vEpiphyte]

Testing henryii's solution in #264 (comment) did not work to produce a build that was tagged with the options I provided.

The solution from @abravalheri seems to be the most straightforward and allows for doing dynamic tag generation. With DIST_EXTRA_CONFIG set to a file that is configured properly, python -m build --wheel just does the right thing for me :)

[henryiii]

What command did you run that failed?

Edit, yes, does seem to not work correctly. The cfg method is actually a closer to "correct" workaround anyway, so probably just use that. :) Though @abravalheri is correct, you can't cross compile to Windows ARM using this trick, since cibuildwheel sets DIST_EXTR_CONFIG in that (one) case. You could write out setup.cfg each time, I suppose.

Ideally this bug should get fixed in setuptools, I hope.