Andi Bergmeier added the comment:
I am not the primary contributor to Bazel, so the decision to support
embeddable Python is not mine to make.
That said, it seems to me like embeddable Python is a perfect fit if you want
to have a hermetic Python installation. And I AM actually the person
Andi Bergmeier added the comment:
Gladly.
So imagine you have the following files:
- foobar
- pyfoo
- foo.py
- src
- test
- bar.py
Since Bazel is a build system, you declare (in directory foobar):
py_library(
name = "foo", # abstract name
imports = &
Andi Bergmeier added the comment:
Using the Python API would of course be the preferred way to go.
Sadly that also means that you at minimum have a full compiler and that IMO
seems overkill when you only want to build a Python package or a Python test
(from the end-user point of view
Andi Bergmeier added the comment:
As a result either
a, have a way to modify sys.path and add support for embeddable
b, have no way to modify sys.path and fail very soon should someone try to use
Bazel with a Python embeddable.
Either way the minimum is to have a way to detect which variant
Andi Bergmeier added the comment:
I would like to ship Python hermetically with Bazel (embedding it).
For that the Python embedded seems perfect.
A problem arises since currently Bazel is controlling the search path of Python
via setting PYTHONPATH (which actually worked with Python 3.5.2
New submission from Andi Bergmeier:
While it is nice to have embeddable Python for Windows, currently there seems
to be no way of distinguishing it from a "normal" Python, which reacts quite
differently to its Environment.
Would like to support Embeddable Python (and ._pth), but re
