fix(pyproject): relax validation for non-packages

[abn]

Relates-to: python-poetry/poetry#10031 python-poetry/poetry#10032

Proposing this fix to see what the team makes of this. This ensures that non-package projects do not need to adhere to strict project section requirements.

Summary by Sourcery

Relax project metadata validation for non-package projects.

Bug Fixes:

• Fixed an issue where non-package projects were subject to the same strict project section requirements as package projects.

Tests:

• Added a test case to verify that project creation succeeds for non-package projects even without all required project metadata.

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request fixes an issue where non-package projects were required to adhere to strict project section requirements. It does so by relaxing the validation for non-packages.

Sequence diagram for project validation process

sequenceDiagram
    participant Client
    participant Factory
    participant Validator

    Client->>Factory: validate()
    activate Factory
    Factory->>Factory: get project data
    Factory->>Validator: validate_object(project, 'project-schema')
    activate Validator
    Note over Validator: Filter validation errors<br/>Skip name/version if non-package
    Validator-->>Factory: filtered validation errors
    deactivate Validator
    Factory-->>Client: validation result
    deactivate Factory

Loading

File-Level Changes

Change	Details	Files
Relaxed validation for non-package projects.	Added a check to skip validation of required project properties like name and version when package-mode is false. Added a test case to verify that project creation succeeds for non-package projects even without required project metadata like name and version. Updated the error message to be more informative about the missing required properties for non-package projects if strict mode is enabled or the missing properties are not name or version	src/poetry/core/factory.py tests/test_factory.py
Added a fixture for a non-package project with invalid project metadata.	Created a new fixture file pyproject.toml with only requires-python, package-mode, and dependencies sections to simulate a non-package project with missing project metadata like name and version	tests/fixtures/non_package_mode_with_invalid_project/pyproject.toml

---

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.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a 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. You can also use
  this command to specify where the summary should be inserted.

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.

[sourcery-ai]

Hey @abn - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider moving the regex pattern to module level since it's a constant, though this is a minor optimization.

Here's what I looked at during the review

• 🟢 General issues: all looks good
• 🟢 Security: all looks good
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[Secrus]

I am all for that. Consider it approved from my side.

[radoering]

Thus, we will allow to violate the standard in non-package mode?

[abn]

Yeah, thinking is in a non-package mode those are not required and seems to be a foot gun mostly. But that is just my thinking atm, I am not strongly for or against this approach. Seems better as user's seem to not expect non-packages to need these properties - I tend to agree, at least for version.

[dimbleby]

violate the standard in non-package mode?

that is of course exactly the objection to this approach. (All these years of folk beating up on poetry for not following PEP621 - and now here we go...!)

IMO the compliant and consistent thing is to tell people that if they don't want a package then they shouldn't be using the project table: because the whole point of that table is packaging, and it is defined by the python packaging authority, and poetry has no business changing the rules for how it is used.

(In that case, it may be that that there are some tool.poetry.xxx bits that should be considered not-deprecated in non-packaging mode: because the corresponding project.xxx is not a good replacement in non-packaging mode.)

While I think this all is mostly not very important, I bet that it will sooner or later cause bug reports and incompatibilities. Eg there will be folk using some tool foo which also uses pyproject.toml - and when foo does not work properly with non-compliant files, they're going to complain here.

[finswimmer]

I agree with @dimbleby as already mentioned on discord. :)

If we keep the current behavior, we could at least improve the error message to guide people into the correct direction.

[dimbleby]

I guess if you wanted to talk yourself into believing that what is proposed here is compliant, you could argue that

• PEP621 does not apply at all in non-packaging mode
• the project table that poetry uses in non-packaging mode is not the same as the project table in the PyPA specifications
  • but as a convenience for users, it just happens to look almost exactly like it.

I don't love this line of reasoning! But it has its merits.

A hole in this logic again comes with other tools foo.

• It's all very well for poetry to declare that it has set non-packaging mode and so it can ignore the standard
• but the only tool that should read tool.poetry.package-mode is poetry itself, so far as anyone else is concerned a project table should just be a regular project table.

[radoering]

We could also take a middle path: We do not create non-compliant project sections (poetry init), but we are able to work with them. However, the question would still be what to do in poetry check.

[abn]

(In that case, it may be that that there are some tool.poetry.xxx bits that should be considered not-deprecated in non-packaging mode: because the corresponding project.xxx is not a good replacement in non-packaging mode.)

This is what motivated me proposing this. If we say that properties available in project are not deprecated in tool.poetry when using package-mode = false, we can have a more rigid stance.

We could also take a middle path: We do not create non-compliant project sections (poetry init), but we are able to work with them. However, the question would still be what to do in poetry check.

Does this mean poetry wont use project section, when let's say poetry add <dep> is used when package-mode = false ? In that case, with check, we can enforce that a project section cannot exist with package-mode = false.

[abn]

To add to this, we could also improve cli usability to add features that let users do poetry <new|init> --non-package and decide on what is generated. But there are several places we will have to support this branching.

[radoering]

Does this mean poetry wont use project section, when let's say poetry add <dep> is used when package-mode = false ? In that case, with check, we can enforce that a project section cannot exist with package-mode = false.

My thinking was that Poetry will use the project section if it exists. It will not care if the existing project section is standard-compliant or not, it will just keep the state of standard-compliance. However, if the project section does not exist it will add the dependency to tool.poetry.dependencies, not creating a non-standard-compliant project section.

Your proposal solves the check issue, but I think there will be users who want to use the project section in non-package mode. And I would strongly argue that we should at least allow to use a standard-compliant project section in non-package mode.

[abn]

I am okay with that approach. In this case I think we can reject this and make the needed changes in the frontend.

[johnthagen]

I think there will be users who want to use the project section in non-package mode.

Yes, many of us see PEP 621 (for all of its ... unfortunate design choices for dependencies formatting) as the way now, so there is a big onus to adopting it in all cases. It's valuable to align with the rest of the community whenever possible.

PEP621 does not apply at all in non-packaging mode

This was my original thinking for python-poetry/poetry#10031 as well. I see the requirements imposed on [project] to make sense for a package that might be installed from sdist and into a wheel.

But I can also see the counter argument against this.

As example what other tools do in this space, uv requires name and version, but Rye does not

• Add a non-package-mode astral-sh/uv#10204 (comment)
• Add a non-package-mode astral-sh/uv#10204 (comment)