Upgrading py-poetry-core and pep517

David Gilman davidgilman1 at gmail.com
Wed Sep 14 01:45:19 UTC 2022


I confirm what you're seeing: a system with just py-poetry-core can
successfully upgrade py-poetry-core, but a system with the whole
poetry suite is failing when doing a `port upgrade poetry` and it goes
to build py-poetry-core.

Furthermore, I was able to reproduce this in a venv with
poetry==1.1.15 installed in it. I'll try taking it upstream but I am
not too hopeful there.

On Tue, Sep 13, 2022 at 12:06 PM Joshua Root <jmr at macports.org> wrote:
>
> I've tried this now myself and I can't reproduce the issue. It seems
> poetry-core at least has no problem building with an older version of
> itself installed, though this doesn't rule out some interaction with the
> other ports being updated in the PR.
>
> % port installed py310-poetry-core
> The following ports are currently installed:
>    py310-poetry-core @1.0.8_0 (active)
> % port info --version py310-poetry-core
> version: 1.1.0
> % sudo port -s upgrade py310-poetry-core
> --->  Computing dependencies for py310-poetry-core
> --->  Fetching distfiles for py310-poetry-core
> --->  Verifying checksums for py310-poetry-core
> --->  Extracting py310-poetry-core
> --->  Configuring py310-poetry-core
> --->  Building py310-poetry-core
> --->  Staging py310-poetry-core into destroot
> --->  Installing py310-poetry-core @1.1.0_0
> --->  Cleaning py310-poetry-core
> --->  Computing dependencies for py310-poetry-core
> --->  Deactivating py310-poetry-core @1.0.8_0
> --->  Cleaning py310-poetry-core
> --->  Activating py310-poetry-core @1.1.0_0
> --->  Cleaning py310-poetry-core
>
> - Josh
>
> On 2022-9-13 10:20 , David Gilman wrote:
> > 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
:DG<


More information about the macports-dev mailing list