bazel: Bump rules_python version to 0.1.0

[phlax]

Signed-off-by: Ryan Northey ryan@synca.io

Commit Message: bazel: Bump rules_python version to 0.1.0
Additional Description:

afaict the current rules_python has quite a few things that dont work correctly - namespaced packages, entrypoints and wheels eg

version 0.1.0 at least seems to fix the issue of namespaced packages, and possibly other problems too

Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

[repokitteh-read-only]

CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).

🐱

Caused by: #15236 was opened by phlax.

see: more, trace.

[phlax]

my understading of https://github.com/bazelbuild/rules_python#importing-pip-dependencies-with-pip_import-legacy is that we need to shift the pattern we currently use of pip_import + reimporting a generated bzl file -> just using pip_install

doing so (with the updated rules_python) does seem to fix the problem i had with namespace packages, but it has caused a different error re test/use_category labels - investigating further ...

[phlax]

afaict here

https://github.com/bazelbuild/rules_python#importing-pip-dependencies

it suggests that the python interpreter is set in the pip_install invokation (with a default of python3) - so i think the PY3 args are not required - im going to try and remove

edit: ignore - this is the interpreter for the py_binary not the deps

[phlax]

hmm - this is hitting what looks like a windows bug here:

https://dev.azure.com/cncf/envoy/_build/results?buildId=67743&view=logs&j=b840a642-5ff3-5357-2e4b-e06e40b0cffd&t=67965174-5100-5631-9dc0-68b9f0aacb53&l=1128

i think the issue is this one:

pypa/setuptools#1902

[htuch]

@wrowe @davinci26 any thoughts on the Windows issue? Thanks.

[sunjayBhatia]

hmm - this is hitting what looks like a windows bug here:

https://dev.azure.com/cncf/envoy/_build/results?buildId=67743&view=logs&j=b840a642-5ff3-5357-2e4b-e06e40b0cffd&t=67965174-5100-5631-9dc0-68b9f0aacb53&l=1128

i think the issue is this one:

pypa/setuptools#1902

I think this is the same issue I think I had solved for #14329 but was never added to the PR branch

See this comment thread: #14329 (comment)

[htuch]

@moderation can you take a look as dep shepherd? I seem to remember a previous patch like this..

[moderation]

@phlax This was my prior PR where I couldn't get around the Windows issues - #14329. I think I missed @sunjayBhatia going into the holidays and like @htuch dislike carrying patches as they add friction to future upgrades.

With this change it is possible to consolidate bazel/repositories_extra.bzl and bazel/dependency_imports.bzl which is a nice reduction in dependency locations. OK to do this in a follow up.

[phlax]

...and like @htuch dislike carrying patches as they add friction to future upgrades.

yep me too - i have opened the ticket upstream to address

im just testing with version 44.1 - if that works we can avoid the patch by using rules_python from their master

[moderation]

Change to using developer provided tarball. Consider consolidating dependency locations.

[phlax]

@moderation @htuch

unfortunately the version of setuptools on current rules_python master doesnt fix the problem (ie setuptools==44.1)

i have raised a PR upstrem bazel-contrib/rules_python#422 to address

in line with your comment here @moderation - #15236 (comment) - i will switch to use the release tarball

this still means using the patch for now - if my PR is landed upstream we probs want to revert to using non-release tarball again - but we will be able to eliminate the patch that way

ill update this pr now...

[htuch]

Looks good, just a couple of minor things.
/wait

[phlax]

as an update to the upstream resolution - it seems it wont land too quickly bazel-contrib/rules_python#422 (comment)

[htuch]

LGTM, thanks!

[htuch]

/lgtm deps