python-poetry / python-poetry/poetry
Poetry build sets python core metadata summary equals description, failing to upload to pypi and pypitest
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 34.3k
- Forks
- 2.5k
- Avg merge
- 2d 19h
- Merged PRs (30d)
- 30
Description
- Poetry version: 1.6.1
- Python version: Python 3.10
- OS version and name: Ubuntu 22.04
- pyproject.toml: (https://gist.github.com/broeder-j/20eb8dc8046fc004608e6acf3bf36236)
Issue
The python package build successfully by poetry gets rejected from PYPI and PYPI test for having a too long summary (512 chars), a package core metadata property.
From my understanding this occurs because:
- poetry sets per default the summary key for core package metadata equals the projects description or empty. (I have not found any way to provide this metadata key additionally to poetry.)
- The summary metadata string is limited to 512 chars on pypi. (I have not found this specification length detail in the specifications https://packaging.python.org/en/latest/specifications/core-metadata/#summary by python beyond that it should be 'one line'.)
- the 'summary' core metadata key is not part of project metadata, so it cannot be set in the pyproject.toml file.
So currently I am forced by poetry to shorten my projects description, that it also fits into the core metadata summary content for PYPI, or I cannot publish the build package there, or I would have to hack the metadata afterwards.
How this might be solved to my understanding by poetry:
- Either provide an external way to specify the core package metadata, like allowing to set the summary in the tools.poetry section or over the commandline.
- An earlier failure, or warning would be nice, i.e if the summary is to long for a pypi upload, that it does not fail on upload, but fails/warns earlier during build.
- shorten the core package metadata summary by default, if to long, or make it an empty string.
Output
$ poetry config virtualenvs.in-project true
$ poetry install
Installing dependencies from lock file
No dependencies to install or update
Installing the current project: test-poetry-issue (1.0.0)
$ poetry build
Building test-poetry-issue (1.0.0)
- Building sdist
- Built test-poetry-issue-1.0.0.tar.gz
- Building wheel
- Built test-poetry-issue-1.0.0-py3-none-any.whl
$ poetry config repositories.testpypi "https://test.pypi.org/legacy/"
$ poetry publish -r testpypi -u "__token__" -p "${testpypi_api_token}"
Publishing test-poetry-issue (1.1.0) to testpypi
- Uploading test-poetry-issue-1.0.0-py3-none-any.whl 0%
- Uploading test-poetry-issue-1.0.0-py3-none-any.whl 10%
- Uploading test-poetry-issue-1.0.0-py3-none-any.whl 100%
HTTP Error 400: 'Long description...long description.' is an invalid value for Summary. Error: Field cannot be longer than 512 characters. See https://packaging.python.org/specifications/core-metadata for more information. | b"<html>\n <head>\n <title>400 'Long description...long description.' is an invalid value for Summary. Error: Field cannot be longer than 512 characters. See https://packaging.python.org/specifications/core-metadata for more information.\n \n <body>\n <h1>400 'Long description...long description.' is an invalid value for Summary. Error: Field cannot be longer than 512 characters. See https://packaging.python.org/specifications/core-metadata for more information.\n The server could not comply with the request since it is either malformed or otherwise incorrect.
The same goes for
poetry publish -u "__token__" -p "${pypi_api_token}"
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the issue with the linked pyproject.toml and a description exceeding the 512-character Summary limit. Inspect the Poetry build and publish entry points to determine where project description becomes core metadata, then verify the chosen validation or warning behavior against both sdist and wheel uploads.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system, release
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100