Add initial warnings regarding license-files glob patterns.

[abravalheri]

The PEP specifies that tools should reject any patterns which contain not-approved chars.
Furthermore, it should be an error if a pattern doesn't match any files.

Ref: #4829 (comment)

This by no means introduces an exhaustive check, just the low hanging fruits.

I intentionally do not analyse each pattern individually here to avoid wreaking too much havoc (imagine e.g. project templates that adds a very general catch all list of patterns in setup.cfg).

Regarding the glob patterns, I am keeping loose for the time being, would like to avoid adding a regex for each pattern if possible, but open to it...

/cc @cdce8p

Pull Request Checklist

• Changes have tests
• News fragment added in newsfragments/.
  (See documentation for details)

[cdce8p]

I intentionally do not analyse each pattern individually here to avoid wreaking too much havoc (imagine e.g. project templates that adds a very general catch all list of patterns in setup.cfg).

I also started working on this before I saw you've opened this PR. As I chose a slightly different approach, I finished it so we could compare them better. See #4841

I explicitly decided to check that each glob pattern match at least one file as I think this is by far the most useful check to have. It's a fallback to make sure files actually get matched. I don't think project templates are a big deal. They either didn't add it in the first place as setuptools provided good defaults early on or used a value specific to their configuration. Why should they have added multiple patterns if they didn't use these files?

[abravalheri]

Thank you very much @cdce8p, I tried to incorporate the validations from #4841 into this one according to the discussion in #4841 (comment).

[cdce8p]

Looks good to me. Adding the enforce_match argument makes a lot of sense. Will go ahead and close my PR then.

[abravalheri]

Thank you very much.

Waiting feedback from https://discuss.python.org/t/pep-639-round-3-improving-license-clarity-with-better-package-metadata/53020/174.

[abravalheri]

Interestingly after I merged #4842 and rebased the PR, pytest decided to start ignoring the decorator @pytest.mark.filterwarnings("ignore"):

[cdce8p]

Waiting feedback from https://discuss.python.org/t/pep-639-round-3-improving-license-clarity-with-better-package-metadata/53020/174.

Not sure if you'll even get a response. Just checked hatch and pdm-backend as these were the first to add PEP 639 support. However, both only seem to do at best a fairly limited validation.

Hatchling only seems to check that the pattern is a str and uses glob afterwards.
https://github.com/pypa/hatch/blob/64031c1cf5d02d85203f68cb7a4fd5db2aa7a004/backend/src/hatchling/metadata/core.py#L758-L768

Pdm-backend doesn't even do glob matching for user supplied values 🤷🏻‍♂️
https://github.com/pdm-project/pdm-backend/blob/4bd3755565a37667457a7a7d079be5f347a551c4/src/pdm/backend/base.py#L277-L291

Poetry hasn't added support yet AFAIK and flit isn't a good comparison since I contributed the pattern validation there.

--
To summarize, the checks as they are right now, seem to match the specification. Maybe that's good enough for now. If someone reports an issue / deviation from the spec, it's always possible to refine it later.

[cdce8p]

Interestingly after I merged #4842 and rebased the PR, pytest decided to start ignoring the decorator @pytest.mark.filterwarnings("ignore")

In #4841 I used monkeypatch. That would probably work here as well by patching _find_pattern.

[abravalheri]

Than you very much @cdce8p. I updated the PR based on your feedback.

[cdce8p]

LGTM. As mentioned earlier, I'm not sure there will be feedback on this in the forum. It's probably a case for iterative improvements. See what works and where the pain points are.