Pull in importlib_resources 3.2.0 for py3.5 and 3.6

[fahhem]

importlib.resources is added in py3.7, but py3.5 and 3.6 don't have it. Technically, they are EoL'd, so if you don't want to support this that's fine, but we'll have to support it internally via this patch.

This PR also does a few things that I can split out if you prefer:

• rename entrypoints to start with entry_point_ (to avoid shadowing runfiles with binaries named the same as the pkg)
• Add a entry_point() function next to requirement()

[fahhem]

ready for review

[ali5h]

I don't think we need to add the support for EOL pythons

[ali5h]

@fahhem can we find a way to access the entrypoint like @pkg//bin/:script? would there be any shadowing issue in that case?

[fahhem]

I tried, but the filename is already bin/x and I can't call it bin/x.py otherwise it will import itself. @pkg//:bin-script is the best I could do

[ali5h]

looks good, do we use importlib_resources anywhere?

[ali5h]

looks like all the changes to third_party can be reverted?

[fahhem]

I need 3.6 support at work, we have a customer that won't upgrade :/

[ali5h]

but i don't see it imported anywhere. is that ok?

[fahhem]

It's used in third_party/py/installer/scripts.py: https://github.com/ali5h/rules_pip/pull/75/files#diff-5df66d4ca225891ccf85b4ac26e40045a6724ad3eaca8ed511bc1a8867b72f00

[ali5h]

so you manually edited that file? Everything in third_party/py must exactly match the upstream. and also added to src/requirements.txt, basically pip install -t third_party/py -r "src/requirements.txt" --no-deps -U should result in no change to the repo.

[ali5h]

i took the liberty and rebased this branch on master, which i added a test for checking the integrity of third_party/py

[fahhem]

oh, thanks!

[fahhem]

okay, I found a way to support python 3.5+ by using an older installer instead