restore PEP-517 support

[graingert]

Rationale

pip installs are not currently compliant with PEP-517. This PEP is relied upon by external tooling. This behavior was reverted in 454a911 because it made it harder to test cartopy against a set particular version of numpy. IMO it is not necessary to remove PEP-517 compliance to enable this testing pattern. Using python setup.py develop versus pip install is enough. See this example:

bash-5.0$ python -m venv .env
bash-5.0$ source .env/bin/activate
(.env) bash-5.0$ pip install numpy==1.18
Collecting numpy==1.18
  Using cached https://files.pythonhosted.org/packages/f0/14/f71a89e03578084111e352f464d9f3b7f701ebbecbd1a60e89c96983ef77/numpy-1.18.0-cp37-cp37m-macosx_10_9_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.18.0
(.env) bash-5.0$ pip install .
Processing /Users/noah/workspace/cartopy
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  Complete output from command /Users/noah/workspace/cartopy/.env/bin/python /Users/noah/workspace/cartopy/.env/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /var/folders/l1/hgxljmwd51vdlxhnnd272mqm0000gn/T/tmpd1r2bc61:
  MY NUMPY VERSION IS 1.19.4

  ----------------------------------------
Command "/Users/noah/workspace/cartopy/.env/bin/python /Users/noah/workspace/cartopy/.env/lib/python3.7/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /var/folders/l1/hgxljmwd51vdlxhnnd272mqm0000gn/T/tmpd1r2bc61" failed with error code 1 in /private/var/folders/l1/hgxljmwd51vdlxhnnd272mqm0000gn/T/pip-req-build-i17lx8mw
(.env) bash-5.0$ python setup.py  develop
MY NUMPY VERSION IS 1.18.0

Implications

Cannot pip install cartopy with one pip command.
Checklist

If you have not already done so, ensure you've read and signed the Contributor Licence Agreement (CLA).
(See the governance page for the CLA and what to do with it).

If this is a new feature, please provide an example of its use in the description. We may want to make a
follow-on pull request to put the example in the gallery!

Ensure there is a suitable item in the cartopy test suite for the change you are proposing.

Fixes #1552.

based on #1680

[graingert]

cartopy only supports python 3.5+, and numpy only started 3.5 support in v1.13.3

[greglucas]

We are actually only testing against 3.6 on master now, so it is even newer than that!

[graingert]

probably worth doing NEP29 and pyupgrade in a follow-up PR

[thijsvanwinden]

+1 for making cartopy PEP-517 complaint again. This simplifies usage of this package alot on modern serverless architectures with limited configuration options other than requirements.txt. Now we automatically resort to custom docker images because we need multiple installation steps to install all dependencies.

[dopplershift]

@thijsvanwinden Wouldn't you still have issues with needing to build against GEOS and PROJ? Those dependencies can't appear in pyproject.toml.

[thijsvanwinden]

You are totally right. Overlooked that in my build script when updating to the cartopy 0.18. Still I think PEP-517 compliance is desirable.

[graingert]

You'll still have the same problems with GEOS and PROJ, but that's much easier to solve than installing numpy before cartopy

[greglucas]

I agree with the sentiment here that this simplifies the pip installs all being on one line and it doesn't seem to have much of a downside as far as I can tell? Sure, you'll have to install the other packages, but that was the case even before this PR.

[dopplershift]

To be clear, I'm 👍 on this in principle, just don't want anyone thinking it's a magic bullet solving CartoPy install issues. It's definitely a step forward, though,

[greglucas]

Thanks @graingert! I think this will help. We can add other fixes in later if we need to clarify anything.

[graingert]

@greglucas can you make a 0.19a0 pre-release with this in? I'm currently pulling it from my personal github repo

[greglucas]

That would be fine with me. I've been waiting for review of PRs from the list on #1703 before doing the release, but I don't see why those couldn't be put in after a pre-release? Honestly, at this point maybe we just need to get a 0.19 out the door and those can go into 0.20.

@dopplershift and @QuLogic do you have any objections/thoughts?