Declare rules_python deps

[katre]

[Previous text moved to #179]

Add correct lxml dep in rules_python setup, fixing #179.

[katre]

Okay, after some work and updates I at least have consistent failures: without bzlmod, enforce_min_sdk_floor can't run because the python toolchain can't find the binary dependencies on lxml (this is an assumption but seems justified after checking similar error reports in other programs).

I don't know why bzlmod works here, and what it's doing differently.

[katre]

Managed to set up a docker image that mimics CI, and it looks like the (successful) bzlmod version is using python 3.11, and the (unsuccessful) non-bzlmod version is using python 3.8:

11c11
<     lxml/site-packages/lxml/_elementpath.cpython-311-x86_64-linux-gnu.so,
---
>     lxml/site-packages/lxml/_elementpath.cpython-38-x86_64-linux-gnu.so,
14c14
<     lxml/site-packages/lxml/builder.cpython-311-x86_64-linux-gnu.so,
---
>     lxml/site-packages/lxml/builder.cpython-38-x86_64-linux-gnu.so,

[katre]

Okay, that solved it for linux, mac intel and mac arm apparently need separate vendored_requirements files because of the interpreter difference. I'll try a bit more and see if I can poke this.

[ted-xie]

Thanks for looking into this!

Managed to set up a docker image that mimics CI, and it looks like the (successful) bzlmod version is using python 3.11, and the (unsuccessful) non-bzlmod version is using python 3.8:

wat, there are two different versions of python used in two different build pipelines in BazelCI?

[ted-xie]

There's no specific version of lxml specified here, so pip will always try to pull the latest available one, right? In that case, wouldn't the requirements_lock.txt file be invalidated frequently?

[katre]

I believe it's locked to the latest version when the lockfile was last updated.

It'd probably be better to explicitly specify a version, but that's down the chain after "make the thing work cross-platform".

[katre]

Yes, the Mac workers and the Ubuntu workers have different versions installed.

Ideally, we wouldn't have system python on either, and just use a hermetic python toolchain for everything.

To summarize the problem for rules_android:

1. To use a hermetic python toolchain is easy with bzlmod
   1. We don't publish a bzlmod version of rules_android for users, even though it's possible to build inside rules_android with bzlmod
2. To use a hermetic python toolchain without bzlmod, we'd need a third-stage WORKSPACE macro (after rules_android_prereqs and rules_android_workspace
   1. It's possible to vendor the needed deps files, except that they have architecture dependencies, so can't work for us.