Building wheels

[dpdani]

Hi 👋

I'm looking to build a package to be used with this interpreter. I can't seem to be able to correctly build it, and I'm presuming it has something to do with the nogil naming of the built wheel. In particular, hatch complains with this error:

$ hatch env create
  WARNING: Built editable for cereggii is invalid: cereggii-0.0.1--none-any.whl is not a valid wheel filename.
ERROR: Could not build wheels for cereggii, which is required to install pyproject.toml-based projects

While the package can be built correctly:

$ python -m build 
* Creating virtualenv isolated environment...
* Installing packages in isolated environment... (hatchling)
* Getting build dependencies for sdist...
* Building sdist...
* Building wheel from sdist
* Creating virtualenv isolated environment...
* Installing packages in isolated environment... (hatchling)
* Getting build dependencies for wheel...
* Building wheel...
Successfully built cereggii-0.0.1.tar.gz and cereggii-0.0.1--none-any.whl

Of course, with this being an experimental interpreter, hatch is not expected to support it. Do you know of possible workarounds?

[colesbury]

If you're able to point me to an public project where this happens, I can look into it.

If your project does not require any native components, you may be able to build the wheel with CPython and then run it with nogil as a workaround.

[dpdani]

Sorry, I'll be publishing the repo as soon as it makes sense, for now it's all just a mess.

By native components you mean C extensions? Because yes, there is some C code involved.

[colesbury]

Ok, let me know when when the repo is public. I have not seen this error before and will not be able to help without a way to reproduce the bug.

[dpdani]

Hello again 👋

I've published https://github.com/dpdani/cereggii/tree/feature/build

If you try execute this snippet:

git clone https://github.com/dpdani/cereggii
git checkout feature/build
git pull
pyenv shell nogil-3.9.10-1
pip install hatch
hatch env create
pip install build
python -m build

you should see the errors above.

[dpdani]

(the C part is just a dummy taken from https://docs.python.org/3/extending/extending.html)

[colesbury]

This is not a valid wheel filename: cereggii-0.0.1--none-any.whl. You probably can't specify requires-python = "==3.9.10" or your wheel will not be properly tagged (this is true with upstream CPython too).

[dpdani]

Yes, that was indeed the problem :+1:

I'm setting requires-python = "~=3.9" and both build and hatch manage to create a wheel with a correct name.

I've only loosely followed the discussion about ABI tags in wheels for nogil. Right now both tools are setting it to none for this project, is there a better alternative, or is it fine?

[colesbury]

If you are using the C-API (i.e., in spammodule.c) then that none in the ABI tag does not look correct. That's not a nogil issue -- it looks like you have the same problem with CPython.

[dpdani]

And would there be a tag specific to nogil?

[dpdani]

I read here that there would be a t suffix to add. Of course, with the PEP not being officially accepted yet, there may be changes to that.

But I guess my question really is, would it make sense to publish a wheel to PyPI that has the t suffix (is it even going to be accepted?), or would it be better to use a standard tag, and possibly issue a warning if getattr(sys.flags, 'nogil', False) == False?

[colesbury]

@dpdani, you shouldn't have to set the tag on your wheels. If you have to do that, something has gone wrong. The tool you use to build (i.e., wheel / pip / etc.) should set the tag.

The tags used in this fork are different than the tags that will be used the future CPython 3.13 release (with --disable-gil).

[colesbury]

I'd suggest trying to figure out these issues first using vanilla CPython before trying it out in this fork. I'm familiar with hatch, so there's not much help I can give you there.

[dpdani]

Thanks @colesbury for your help!

I was wondering whether it would be better to modify the output filename in order to make it clear for a user downloading the package that the expected interpreter was not the standard one, but resorting to a warning should be fine. After all, both this interpreter and the library I'm writing are experimental anyway. I'll just make it clear in the readme.

(p.s. in the end I had to stop using hatch altogether)