PEP 508 defines an environment marker as

> a rule that describes when the dependency should be used

Such marker does a very good job at describing which environment
a dependency is needed, including Python version and implementation,
OS and architecture.  Sometimes, env markers are also used to guard
against environments where a package is not usable.  I suppose that
this is not the canonical use case, but it also work well.

Such work-around exists because there lacks facilities to precisely
specify compatibility.  Source distributions, especially ones
using setuptools can check at build time but it's rather inconsistent
and they are out of our scope.  For wheels, there are two indicators:

* Requires-Python (from METADATA 1.2, see PEP 345): Python version
* Wheel tag (PEP 425): Python version, impl and ABI, OS and arch

While the latter could in theory does the same as markers, providing
exhaustive list if supported environments is rather cumbersome
in some cases.  Takes WMI, a pure Python package that only works
on Windows, for instance: its platform tag would have to be
somewhere along the line of win32.windows_amd64.etc; and I don't think
there's even an PEP 517 back-end supporting generating it.

Furthermore, as downstream developers (read: integrators), we need a way
to tailor which wheel goes where.  Thus, I propose the following change
to the TOML declaration:

* Remove the optional `requires-python` field
* Add `markers` as a compulsory field, which is an array of strings

For example:

markers = [
	'python_version >= "3.7"',
	'platform_system == "Windows"',
]

Self markers need not repeat platform tags, but can be advisable
in case they clarify the installation target.

I would love to hear feedback before implementing this.  In addition,
if it works for our floating cheeses, we can consider proposing this
for Python packaging formats, starting with sdists (PEP 621)
and metadata.

I don't have any opposition to the change (Other than that, it'd be such
a chore), but how about using key-value, which (probably) is easier to
handle?

```toml
[markers]
python_version = ">=3.7"
platform_system = "Windows"
```

> I don't have any opposition to the change

I'm glad to hear that.  Now that you said it, *markers* is not
the right name because it was for the context of it marking
the dependency.  Any suggestion?

> (Other than that, it'd be such a chore)

It can and must be automated, no worries.

> but how about using key-value, which (probably) is easier to handle?
>
> ```toml
> [markers]
> python_version = ">=3.7"
> platform_system = "Windows"
> ```

Not exactly, since packaging.markers take the entire string
to initialize.  I know that e.g. poetry does this for version specifers,
but I don't find `= ">=3.7"` very intuitive and PEP 621 also goes
with full strings (mostly because packaging can parse them).

> Now that you said it, *markers* is not the right name because it was
> for the context of it marking the dependency.  Any suggestion?

I'll go first: "environment", since it describes the approriate
environment for the wheel.  It should also be a string instead
of a list since that's how packaging parses env markers, plus
predicates are linked together via `and' and `or' so properly
splitting them is impossible.

It also doesn't make sense to have an empty environment, so let's
keep it an optional field like what it's supposed to replace.

For e.g. Hypercorn[uvloop] and Twisted[macos_platform] we'll also need
markers for extras.  I'm thinking of borrowing the maker syntax, e.g.

    extras = [
    	'macos_platform; platform_system == "Darwin"',
    	'windows_platform; platform_system == "Windows"',
    	# ...
    ]