feat: allow publishing artifacts if version is determined dynamically

[radoering]

Pull Request Check List

• [x] Added tests for changed code.
• [x] Updated documentation for changed code.

Until now, poetry publish did only upload artifacts that matched the name and the version in the pyproject.toml. This PR changes this constraint so that artifacts of the latest version in the dist directory are uploaded. (The name is still matched.) This is useful if some kind of dynamic versioning is used, e.g.:

• poetry build --local-version
• poetry plugins for dynamic versioning
• an alternative build backend, which supports dynamic versioning (cf Support for alternative build backends in Poetry )

Summary by Sourcery

Allow publishing the latest built distribution artifacts regardless of the static version in pyproject, improving support for dynamic versioning scenarios.

New Features:

• Select distribution files to publish based on the latest available version in the dist directory rather than the version declared in pyproject.toml.
• Expose the resolved artifact version from the uploader so the publisher can display the actual published version.

Enhancements:

• Update uploader registration to reuse the selected distribution artifacts instead of requiring a version-matched sdist.
• Clarify CLI docs for poetry publish to describe how artifacts are selected from the dist directory.

Tests:

• Add tests verifying that the uploader only considers artifacts for the current project name and only uploads files for the latest version, including local version identifiers.
• Adjust publisher and uploader tests to reflect the new artifact selection and registration behavior.

[sourcery-ai[bot]]

Reviewer's Guide

Adjusts Poetry’s publish flow so that artifacts are selected based on the latest built distribution version on disk rather than the version in pyproject.toml, updates uploader behavior and messaging to use this detected version, refines registration behavior, and documents the new behavior, with accompanying tests.

Sequence diagram for dynamic version detection during publish

sequenceDiagram
    actor User
    participant PublishCommand
    participant Publisher
    participant Uploader
    participant FileSystem

    User ->> PublishCommand: run poetry publish --build
    PublishCommand ->> PublishCommand: determine dist_dir
    PublishCommand ->> PublishCommand: call build with --output dist_dir
    PublishCommand ->> Publisher: create Publisher(poetry, io, dist_dir)
    Publisher ->> Uploader: create Uploader(poetry, io, dist_dir)

    PublishCommand ->> Publisher: publish(repository, username, password)
    Publisher ->> Uploader: access files
    activate Uploader
    Uploader ->> FileSystem: list dist_dir matching dist_name-*-*.whl
    Uploader ->> FileSystem: list dist_dir matching dist_name-*.tar.gz
    Uploader ->> Uploader: group artifacts by parsed version
    Uploader ->> Uploader: select latest version via Version.parse
    Uploader ->> Uploader: sort artifacts (prefer wheels)
    Uploader -->> Publisher: return files and version
    deactivate Uploader

    Publisher ->> Publisher: log package pretty_name and uploader.version
    loop for each file
        Publisher ->> Uploader: _register(session, url) or upload
        Uploader ->> FileSystem: open file
        Uploader -->> Publisher: upload response
    end

    Publisher -->> PublishCommand: publish result
    PublishCommand -->> User: show publish summary with detected version

Class diagram for dynamic artifact selection in publish flow

classDiagram
    class PublishCommand {
        +handle() int
    }

    class Publisher {
        -Poetry _poetry
        -IO _io
        -Uploader _uploader
        -Package _package
        +Publisher(poetry, io, dist_dir)
        +publish(repository, username, password) int
    }

    class Uploader {
        -Poetry _poetry
        -string _dist_name
        -IO _io
        -Path _dist_dir
        -string _username
        -string _password
        +Uploader(poetry, io, dist_dir)
        +dist_dir Path
        +files list~Path~
        +version string
        +auth(username, password) void
        +_register(session, url) Response
        +post_data(file) dict
        +_files_and_version tuple~list~Path~~, string~
    }

    PublishCommand --> Publisher : uses
    Publisher --> Uploader : composes
    Uploader --> Poetry : uses
    Uploader --> IO : uses
    Publisher --> Package : reads

File-Level Changes

Change	Details	Files
Uploader now discovers artifacts and their version from the dist directory, selecting only the latest version’s files by distribution name.	Replaced stored package object with precomputed normalized distribution name based on the project name. Introduced a cached helper that scans the dist directory for wheels and source distributions matching the project name, groups them by parsed version (including local versions), and selects the latest version’s artifacts. Exposed selected artifacts and their detected version via new properties, and ordered artifacts so source distributions precede wheels.	src/poetry/publishing/uploader.py
Publisher and publish command now rely on the uploader’s detected version and correctly handle temporary dist directories created by --build.	Changed publish logging to display the uploader’s detected version instead of the static package version. Ensured the Publisher is re-instantiated with the temporary dist directory path after a --build invocation so that artifact discovery runs against the new directory. Kept the existing no-files-to-publish error path but now based it on the uploader’s dynamic file discovery.	src/poetry/publishing/publisher.py src/poetry/console/commands/publish.py
Registration flow uses the dynamically selected artifact instead of assuming a tarball matching pyproject.toml’s version.	Updated the register logic to build its POST payload using the first file returned from the uploader’s file selection instead of constructing a version-specific .tar.gz path. Removed the explicit existence check for the previously assumed sdist file, deferring file presence guarantees to the discovery logic.	src/poetry/publishing/uploader.py
Tests now cover dynamic artifact selection and refined registration behavior, including HTTP interaction expectations.	Added a parametrized test to validate that only the latest version’s artifacts (including local versions) for the correct project name are selected and that the detected version string matches the chosen artifacts. Refactored fixtures to expose a reusable Poetry instance to the uploader tests and added tests to assert that registration triggers both upload and submit actions with the correct form payload. Adjusted publisher tests to stub the uploader’s dynamic version property when asserting behavior that depends on the published version string.	tests/publishing/test_uploader.py tests/publishing/test_publisher.py
Documentation for poetry publish now clarifies that only the latest-version artifacts are uploaded from the dist directory.	Expanded the CLI documentation note to mention that publish uploads only artifacts of the latest version and ignores older builds and artifacts of other packages. Reflowed the surrounding documentation text to accommodate the new warning block.	docs/cli.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an issue from a review comment by replying to it. You can also reply to a review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull request title to generate a title at any time. You can also comment @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in the pull request body to generate a PR summary at any time exactly where you want it. You can also comment @sourcery-ai summary on the pull request to (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the pull request to resolve all Sourcery comments. Useful if you've already addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull request to dismiss all existing Sourcery reviews. Especially useful if you want to start fresh with a new review - don't forget to comment @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.