Upgrading py-poetry-core and pep517

David Gilman davidgilman1 at gmail.com
Tue Sep 13 00:20:28 UTC 2022

So I note that if I drop the --no-isolation from the `python -m build
--wheel` that the python portgroup does I get a wheel built
successfully. I imagine the --no-isolation is there so normal packages
could take advantage of the MacPorts-provided build backend packages.
Maybe it is worth extending the python portgroup to accept some
Portfile option to omit the --no-isolation, which would only be used
on py-poetry-core and the other pep587 build backend packages. I would
hope that the build backend maintainers would maintain this sort of
cross-version compatibility but I could see this problem cropping up
under any of them. I think the ability to bootstrap its own wheel
compilation is not going to bitrot as I imagine they use it frequently
for their own CI and release builds.

On Mon, Sep 12, 2022 at 2:40 AM Joshua Root <jmr at macports.org> wrote:
> On 2022-9-12 06:22 , David Gilman wrote:
> > Log attached. It is a pure upgrade started with "port upgrade poetry".
> The error in the log is actually the pep517 module complaining about the
> backend:
> :info:build Traceback (most recent call last):
> :info:build   File
> "/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/pep517/wrappers.py",
> line 321, in _call_hook
> :info:build     raise BackendInvalid(
> :info:build pep517.wrappers.BackendInvalid
> :info:build ERROR Backend operation failed: BackendInvalid()
> I don't know off the top of my head why this would happen. It might be
> best to ask for help upstream.
> - Josh

David Gilman

More information about the macports-dev mailing list