tool.poetry → project

[DimitriPapadopoulos]

https://python-poetry.org/docs/pyproject#authors

[FirelightFlagboy]

You are confusing project.authors with tool.poetry.authors (it only accept string).

That would require to rewrite the pyproject.toml to use the project section over the tool.poetry

[DimitriPapadopoulos]

Ah, right. But then what's the point of maintaining that information in the poetry-specific tool.poetry table instead of the standard project table? That might have been useful before package metadata was fully standardised, but does not seem relevant any more. Let me give a try to your suggestion.

[FirelightFlagboy]

As you said, it because of legacy, we used poetry before the standardize metadata in project table.
Since our current workflows continue to work, we did not allocated time to migrate to the project table.

[DimitriPapadopoulos]

Note that PEP 639 support was merged into poetry yesterday: python-poetry/poetry#10413. Once this change is released, project.license can be updated according to PEP 639.

[DimitriPapadopoulos]

Some of the CI errors are unrelated: asyncpg 0.29 lacks Python 3.13 wheels, so the build system attempts to build from sources, which fails.

    | asyncpg/pgproto/pgproto.c: In function ‘__Pyx_PyInt_As_uint64_t’:
    | asyncpg/pgproto/pgproto.c:43915:27: error: too few arguments to function ‘_PyLong_AsByteArray’
    | 43915 |                 int ret = _PyLong_AsByteArray((PyLongObject *)v,
    |       |                           ^~~~~~~~~~~~~~~~~~~
    | In file included from /opt/hostedtoolcache/Python/3.13.6/x64/include/python3.13/longobject.h:107,
    |                  from /opt/hostedtoolcache/Python/3.13.6/x64/include/python3.13/Python.h:82,
    |                  from asyncpg/pgproto/pgproto.c:33:
    | /opt/hostedtoolcache/Python/3.13.6/x64/include/python3.13/cpython/longobject.h:111:17: note: declared here

Bumping asyncpg should work because asyncpg 0.30 does ship Python 3.13 wheels. Not sure why building from sources fails at this point.

[DimitriPapadopoulos]

The other issue seems unrelated as well, looks like a Python 3.12-3.13 mix-up not necessarily caused by my changes:

📦 Built wheel for CPython 3.13 to /tmp/tmpibqysb_n/parsec_cloud-3.5.0a6+dev-cp313-cp313-linux_x86_64.whl
extracting /tmp/tmpibqysb_n/parsec_cloud-3.5.0a6+dev-cp313-cp313-linux_x86_64.whl:parsec/_parsec.cpython-312-x86_64-linux-gnu.so -> /home/runner/work/parsec-cloud/parsec-cloud/server/parsec/_parsec.cpython-312-x86_64-linux-gnu.so
Traceback (most recent call last):
  File "/home/runner/work/parsec-cloud/parsec-cloud/server/build.py", line 122, in <module>
    build()
    ~~~~~^^
  File "/home/runner/work/parsec-cloud/parsec-cloud/server/build.py", line 112, in build
    wheel.extract(libparsec_path, path=BASEDIR)
    ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.13.6/x64/lib/python3.13/zipfile/__init__.py", line 1770, in extract
    return self._extract_member(member, path, pwd)
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/opt/hostedtoolcache/Python/3.13.6/x64/lib/python3.13/zipfile/__init__.py", line 1810, in _extract_member
    member = self.getinfo(member)
  File "/opt/hostedtoolcache/Python/3.13.6/x64/lib/python3.13/zipfile/__init__.py", line 1567, in getinfo
    raise KeyError(
        'There is no item named %r in the archive' % name)
KeyError: "There is no item named 'parsec/_parsec.cpython-312-x86_64-linux-gnu.so' in the archive"

I guess should revert to Python 3.12.

That's one of the main migration issues according to Caret requirements.

[FirelightFlagboy]

For the python version issue: on master it install 3.12.
Your change to the required python version is now >=3.12.0,<4 (which is the correct translation of ^3.12.0) is causing it (the action setup-python-poetry) to install the version 3.13.x.

I think it would be best to use ~=3.12.0 instead

[DimitriPapadopoulos]

I have just:

• fixed (or tried to fix) all translations from caret syntax,
• pinned Python to 3.12 so that 3.13 is not pulled in.

An alternative would be to keep dependencies in the tool.poetry section and add dynamic = [ "dependencies" ] in the project section

[DimitriPapadopoulos]

Now I need a way to fix this:

Group(s) not found: dev (via --with)

I don't know much about poetry, will have to look into the documentation how to define the proper "group" now that dependencies have moved to the project table.

Miss click, want to comment only

[DimitriPapadopoulos]

Almost there.

Note that in some cases, when the rightmost version segment is 0, I could use the compatible release operator ~=. I chose to avoid it for consistent translation of the caret operator.

[FirelightFlagboy]

Errors in Q&A::Check tools version are caused because misc/version-updater.py is using now out-dated regex to check for the specified python version & licence in pyproject.toml files.

[FirelightFlagboy]

LGTM, one last thing would be to squash the commit.
I can do that if you prefer.

[DimitriPapadopoulos]

I would advise against squashing, to discriminate between the manual changes and the last commit which is the result of an automated poetry lock run.

But I'll squash if you insist.