prebuild.py call causes "build error"

[jeff-dh]

SolidPython/pyproject.toml

Line 45 in 4337922

script = "prebuild.py"

For some reason this causes this error over here when I call poetry build:

Preparing build environment with build-system requirements poetry-core>=1.0.0
Building solidpython2 (2.0.1)
Traceback (most recent call last):
  File "/[..]/SolidPython/setup.py", line 2, in <module>
    from setuptools import setup
ModuleNotFoundError: No module named 'setuptools'

Command '['/tmp/tmpkz3ceeao/.venv/bin/python', '/[..]/SolidPython/setup.py', 'build', '-b', '/[..]/SolidPython/build']' returned non-zero exit status 1.

Note: setuptools is installed

changing the pyproject.toml file like this:

[tool.poetry.build]
generate-setup-file = false
script = "prebuild.py"

makes the call work again, but the build process creates a different file!?! solidpython2-2.0.1-cp310-cp310-manylinux_2_35_x86_64.whl instead of solidpython2-2.0.1-py3-none-any.whl

@ssuchter Any idea what's going on there?

[jeff-dh]

maybe related:

python-poetry/poetry#5401

[ssuchter]

Hm, I don't think we need the setup.py file, so how about we just keep the generate-setup-file = false line? I saw that in the examples I looked at (having the generate-setup-file = false) but it worked in my setup, so I didn't think it was important and opted for a shorter change. But if it's breaking your setup, I vote for just fixing it by including the option, without figuring out why.

…

On Fri, Apr 21, 2023 at 4:14 PM jeff ***@***.***> wrote: maybe related: python-poetry/poetry#5401 <python-poetry/poetry#5401> — Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOYJWZ4IWYXWN6ZBD7Y6SDXCMIGNANCNFSM6AAAAAAXHM44WQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jeff-dh]

Well but as mentioned, the output is different. Why is the wheel file a different (at least the name which seems to be less portable, at least the name says so).

[ssuchter]

Hm, I need to try to reproduce your problem. I'll try.

…

On Fri, Apr 21, 2023 at 4:28 PM jeff ***@***.***> wrote: Well but as mentioned, the output is different. Why is the wheel file a different (at least the name which seems to be less portable, at least the name says so). — Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOYJW7AHLPI2WBETHT246TXCMJ3NANCNFSM6AAAAAAXHM44WQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jeff-dh]

Do you have all necessary information?

If you remove the whole [tool.poetry.build] section, it creates a *py3-none-any.whl file (as it used to be). With the prebuild.py call and generate-setup-file = false it produces *cp310-cp310-manylinux_2_35_x86_64.whl which is according to this less compatible.

Does it behave the same on your system?

[ssuchter]

I'll take a look tonight (California time)

[ssuchter]

Ok, I've reproduced the issue, looked through poetry code, and found that for some bizarre reason, poetry doesn't support using a build script and producing a pure python wheel. Others complain about the same issue:

python-poetry/poetry#2051

I'm trying a workaround from that issue now.

[ssuchter]

I think the lack in underlying poetry is hard to work around. I think the right thing to do is to not use the prebuild script. Originally, it was being used to autogenerate stubs, but you changed my mind on that. Now it's just validating that the submodules got initialized, but we can use the tests to validate that now. I'll make a PR for this trivial change.

[ssuchter]

Here's the PR for you: #28