Ignas Anikevicius

Just to clarify what I was thinking about: https://github.com/bazel-contrib/rules_python/blob/c678623fce4b5213b3c7661c166c0dac1ee22661/python/private/runtime_env_toolchain.bzl#L121 This allows the non-hermetic toolchains to work better. One could probable use something similar to enable the `-P` conditionally for only...

The correct way to solve this could be to start using techniques outlined in https://blog.engflow.com/2024/08/20/migrating-to-bazel-modules-aka-bzlmod---repo-names-and-rules_pkg/

Ah sorry, I might be missing something about the original problem. I was reading this blog post and the topics seemed to be related - packaging files.

It seems that `python/private/toolchains_repo.bzl` has `_get_host_os_arch` which could be updated to drop dependency on `uname`.

> Something I ran into as I implemented the above is how the pip repo rules handle namespace packages. Right now, they create a pkgutil style shim -- this confuses...

So for the next steps (after 2908 gets merged) here my ideas are: * we somehow need to add dist info and data to the final venv and it would...

I think the general consensus is that we would eventually like to have a statically linked binary loader and we are using a script for easier prototyping for now.

@mering, #2500 is the issue that is for the statically linked loader, let's discuss how to do it there.

Do we need support for `include`? I think that we probably just want to have a filegroup with includes in it. That said, I see that numpy under `rules_python` does...

I think for the latest bazel version runs we could just use `--lockfile_mode=update`. Is it possible to configure something like this?