Henry Fuller

It's a good question. It looks like the standalone interpreters do ship with a .so file as well. We probably wouldn't want to exclude it anymore https://github.com/bazelbuild/rules_python/blob/main/python/repositories.bzl#L173-L175. @f0rmiga would be...

>Yes, folks will get a clear error message instructing them what to do: >>The `requirements_lock` file must be fully pinned. See `compile_pip_requirements`. Alternatively, use `pip-tools` or a similar mechanism to...

My point has to do with fully-transitively resolved and pinned lock file (what we expect in pip_parse) vs a fully-pinned requirements.txt that only has top level distributions. pip_install would run...

>Is the suggestion you are making @hrfuller to rather NOT try to reuse the existing requirements.txt Not really, just pointing out that the current workaround won't work for some users....

I'm nearly certain these wheels don't ship with bytecode. I think the byte code is getting generated when we use these external repos during repository rule execution. Can you try...

This is an issue with the upstream native bazel rules not rules_python. The problem is that the PYTHONPATH set by the python_stub_template is longer than the allowed system limits. You...

I believe the issue lies with the hermetic interpreters which are now used, apparently by default. The installed interpreters libs don't seem have the correct header files present.

@davians12 I can't repro this exact issue because I develop on macos. Can you put together a repro of the WORKSPACE which create this issue. In particular are you using...

So this issue is basically the linux equivalent of bazelbuild/rules_python#646 but in the integration test I added to #679 I can't repro this failure with linux. To me that implies...

Agreed the @aaliddell bisect makes sense to me.