fix: use original interpreter path as 'home' value in pyvenv.cfg

[mattem]

Use the original (source) interpreters bin path as the 'home' value in the generated pyvenv.cfg file.

Closes #159

---

Type of change

• Bug fix (change which fixes an issue)

For changes visible to end-users

• Suggested release notes are provided below:

Ensure correct home pathing is used when generating the venv.

Test plan

• Covered by existing test cases
• Manual testing; please provide instructions so we can reproduce:

Updated e2e smoke to use py3.11

[shinypb]

Thanks for making this fix, @mattem! This patch absolutely fixed my Python 3.11 woes.

@alexeagle Any chance of you doing a release in the near future? I've pinned our usage of aspect_rules_py to this commit in the meantime, but I'd love to get back to using a bazel_mod statement rather than git_repository if possible.

I appreciate you both! Thank you. 🙇

[alexeagle]

@shinypb sure I'll push a tag right now.

[shinypb]

@alexeagle Howdy! That never made it to the central registry 🤔 It's still showing 0.4.0 as the latest release:
https://registry.bazel.build/modules/aspect_rules_py

[honnix]

Thanks for fixing this.

If I'm not mistaken,

rules_py/py/private/venv/venv.tmpl.sh

Line 142 in e5c2112

echo "home = ${VBIN_LOCATION}" > "${PYVENV_CFG}"

needs the same treatment.

I tried using:

py_venv(
    name = "my_venv",
    deps = ["//src:my_lib"],
)

to create a venv under <workspace root>/.my_venv and the content of pyvenv.cfg is not correct.

Also the content of first_party.path also looks strange:

../../../..
../../../../site-packages
../../../../site-packages
../../../../site-packages
../../../../site-packages
../../../../site-packages
../../../../src
../../../../

I have dependencies of my_lib so I assume those ../../../../site-packages are due to that.

[honnix]

I tried proposing a small fix for the pyvenv.cfg in #228 . Unfortunately I will not be able to sign CLA personally, so please feel free to discard the PR and get the fix in. Thank you.