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 <j...@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 <j...@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<
