Moving to bzlmod ?

[oh-tarnished]

Hey @mvukov , Any plans to move to bzlmod ?

[mvukov]

Hello, I don't have plans to support bzlmod short-term. IMO, it's a good future-proof initiative.

[oh-tarnished]

I was thinking of making a PR. would it be okay ? I think by end of this lifecycle of bazel 6.

[mvukov]

👍 Sounds good.

[oh-tarnished]

Hey Again,

Did you consider moving all the python deps to poetry project ? instead of pip ? I love how poetry handles the dependencies and cross-compile your code.

Someone already made a bazel rules for that we are using it at our company. rules_poetry

suggestion to move all the python deps to poetry .. which would solve the cross compilation for python deps

Pull Request #173

[mvukov]

I am thinking to use poetry as a dep resolver instead of pip-compile. pip-compile cannot resolve deps for another platform, but poetry can -- thinking here about arm64. I have never used rules_poetry. Didn't look into the details, but, not declaring each dep as a separate workspace (but having all deps in a single workspace) doesn't allow for incremental downloads. This could be a serious issue once you have a lot of deps. I've used rules_python when it didn't have incremental downloads and it wasn't so convenient.

How does poetry solve cross-compilation issues? Does it use Bazel-provided cc toolchain(s)?

[oh-tarnished]

Well rules_poetry depends on poetry.lock file which has all the supported wheel files to compile. if for instance the wheel file doesn't exist for a particular architecture then it throws an error out. saying unsupported architecture based. how pip vendors each library for single architecture .... poetry does it for multiple and it doesn't use any cc-toolchains.

[mvukov]

IMO, it's sufficient to track #173.