Switch to PEP621 compliant project metadata.

[freakboy3742]

Replace the use of setup.py and setup.cfg with PEP621 project metadata.

Dependabot has issues when a setup.py is used, but doesn't contain the dependency definition. We historically used setup.py beacuse we needed a dynamic dependency on toga-core for the backends; but we can work around that by providing a custom setuptools plugin.

• Removes all setup.py files
• Removes all setup.cfg files, migrating data to pyproject.toml
• Removes the attic projects. They're in CI if we need them for historical purposes.
• Removes the use of MANIFEST.in. setuptools_scm will populate the source tarball with all version controlled files.
• Removes the use of check-manifest (since there's no manifest to check)
• Root level flake8 configuration has been moved to tox.ini, because flake8 doesn't support pyproject.toml configuration.

Fixes #2226.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

Hold off on merging this; I've got a lead on how we can permanently fix the dynamic dependency issue.

[freakboy3742]

@mhsmith I've been able to completely remove setup.py using the tip that came from @raphaelm There's some unfortunate code duplication, but I don't think we can avoid that without actually publishing a custom build backend... and I don't think PyPI needs that noise. The duplicated code isn't that complicated, and is unlikely to need to change that often, so I think I can hold my nose and live with the code smell.

[freakboy3742]

FWIW: A custom build backend might not be the worst idea, as long as it's not Toga specific.

From a little more investigation, it should be relatively straightforward, using the same entry point to setuptools that setuptools_scm uses (setuptools.finalize_distribution_options). We'd essentially be setting up a module that lets you define install_requires and extras_require in a custom pyproject.toml configuration block, but does format string expansion of {version} in those definitions. I've had enough interest on Mastodon to my question to suggest that there might be a broader interest in this as a feature/package.

[mhsmith]

Even if we don't make an independent build backend, I think it would be better to actually use finalize_distribution_options, rather than monkey-patching an undocumented internal API and potentially causing trouble with future setuptools upgrades.

This could be done as follows:

• Put the backend in its own directory, alongside a .dist-info directory containing an entry_points.txt.
• Give the entry point callable a positive order attiribute so it will run after setuptools-scm. That way, we can pull the version out of the Distribution object rather than depending on setuptools-scm directly. This should reduce the backend implementation to only about 3 lines.

[freakboy3742]

@mhsmith Ok - I've got this working with a setuptools plugin, and no setup.py or setup.cfg files.

[mhsmith]

Better record what those contexts are before you forget, otherwise we'll never know when it's safe to remove this.

[mhsmith]

I've never seen this method of listing platform-specific dependencies. Does it actually work? Even if it does, it might be better to switch to the more conventional semicolon syntax.

[freakboy3742]

It definitely works - it's how the toga-demo install works.

It's based on an edge case of optional (nee - extra) dependency handling. If I remember correctly, back the early days, you could install toga[cocoa] to install a specific backend, and this syntax was there so that the default behavior was to install the right backend if you didn't specify an explicit extra.

However, I agree that doing this as a "base" dependency with conditional install syntax will be less confusing.

[freakboy3742]

We're not actually using this for mobile platforms at present, but I think it would work for the iOS case as it currently stands. android won't be returned on any platform at present, but in the event it ever is, we can be ahead of the situation. FWIW, toga.platform already supports sys.platform == 'android'.