chore(sdist): migrate project.license to SPDX expression

[thisisrick25]

Summary of Changes

Migrate the project license to an SPDX-compliant format and update the setuptools version requirement. Remove redundant OSI license classifier.

Related Issues

closes #2451

Pull Request Checklist

This is just a reminder about the most common mistakes. Please make sure that you tick all appropriate boxes. But please read our contribution guide at least once; it will save you a few review cycles!

If an item doesn't apply to your pull request, check it anyway to make it apparent that there's nothing to do.

• Applied changes to both WSGI and ASGI code paths and interfaces (where applicable).
• Added tests for changed code.
• Prefixed code comments with GitHub nick and an appropriate prefix.
• Coding style is consistent with the rest of the framework.
• Updated documentation for changed code.
  • Added docstrings for any new classes, functions, or modules.
  • Updated docstrings for any modifications to existing code.
  • Updated both WSGI and ASGI docs (where applicable).
  • Added references to new classes, functions, or modules to the relevant RST file under docs/.
  • Updated all relevant supporting documentation files under docs/.
  • A copyright notice is included at the top of any new modules (using your own name or the name of your organization).
  • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
• Changes (and possible deprecations) have towncrier news fragments under docs/_newsfragments/, with the file name format {issue_number}.{fragment_type}.rst. (Run towncrier --draft to ensure it renders correctly.)

If you have any questions to any of the points above, just submit and ask! This checklist is here to help you, not to deter you from contributing!

PR template inspired by the attrs project.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (40ecd71) to head (666bda7).

Additional details and impacted files

@@            Coverage Diff            @@
##            master     #2452   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           64        64           
  Lines         7859      7859           
  Branches      1076      1076           
=========================================
  Hits          7859      7859           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[CaselIT]

Hi, thanks for opening this.

Sadly that version of setuptools is not available in 3.8 that we still support, so before merging we need to decide what's the best option

[vytas7]

Echoing @CaselIT, thanks a lot for this contribution @thisisrick25 , and I'm terribly sorry for marking this as a "good first issue"; I didn't really expect this kind of deprecation timeline from setuptools. (See also: pypa/setuptools#4903.)

We have communicated that 3.8 and 3.9 support are both best effort, and not covered by the SemVer guarantees for Falcon 4.x, so we will probably drop 3.8 support at some point, that is not the main issue here. But I don't want to require the newest version of setuptools because it will make 3rd party packaging hard for the distributions that are using an older version of setuptools for some reason.

[CaselIT]

This is really poorly executed by setuptools. The new syntax breaks on older version of setupools, preventing install at all.
And apparently all the previously supported syntaxes cause a deprecation warning (AFAIK), so everyone needs to change it. I really don't understand why they though it was a good idea...

[thisisrick25]

Hi @CaselIT @vytas7, what should be the next course of action? I am open to keeping this PR open or closed, whatever you suggest.

[vytas7]

@thisisrick25 we can keep this open for a while, maybe we can merge in 4.2 around the end of this year, provided we (1) drop 3.8 support, and (2) explore the ramifications of requiring this relatively new version of setuptools.

[vytas7]

We have dropped 3.8 support in master, but I'm still not 100% comfortable about requiring setuptools 77+ for building the package.

The current version at the time of this writing is 80.x, so ostensibly it looks solid with requiring -3 SemVer major versions behind the current one.

However, 77.0.3 was released in March, less than 6 months ago, which gives a very harsh timeline for anyone (like 3rd party Linux distro packagers) to adapt. That said, I guess the popularity of setuptools has probably forced the distributions to adapt (it's SPDX or the highway), and the most popular ones like Fedora, Debian already sport 78+ from what I've seen.

@abravalheri from setuptools has posted a number of potential workarounds on the issue (pypa/setuptools#4903 (comment)), but none of these options look particularly attractive. Two of them are basically do nothing, which will become a mirror issue later as time goes by. We could still explore the ramifications of resolving the license expression dynamically, or removing the license metadata altogether (but maybe it's still OK to link to the license file?).

[vytas7]

Let's circle back on this after Falcon 4.2. I'm planning to get 4.2 out some time in October, and 4.3 around Christmas.