[issue29503] Make embedded-Python detectable
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 really first need a way of identifying whether it is embeddable or not. -- components: Windows messages: 287344 nosy: Andi Bergmeier, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Make embedded-Python detectable ___ Python tracker <http://bugs.python.org/issue29503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29503] Make embedded-Python detectable
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-embedded for non prefixed paths). Now I do not know whether there is any other way of modifying sys.path when calling python.exe. -- ___ Python tracker <http://bugs.python.org/issue29503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29503] Make embedded-Python detectable
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 it is. -- ___ Python tracker <http://bugs.python.org/issue29503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29503] Make embedded-Python detectable
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). The ._pth would be perfect if I could place it alongside the .py script I want to execute. BTW: Can you please remove PYTHONPATH from the help message and so forth for the embeddable variant. Can be misleading. -- ___ Python tracker <http://bugs.python.org/issue29503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29503] Make embedded-Python detectable
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 = ".", srcs = ["pyfoo/foo.py"], # Which source files are in that library ) py_test( name = "bartest", srcs = ["pyfoo/src/test/bar.py"], # The test script deps = ["foo"], # "Will import foo" -> import of foo's parent directory is added when executing test ) Bazel does not ship with a specific Python version. So you (the user) start Bazel and provide it with a path to a Python on your system. This means that the Python version MAY be different on every execution of Bazel. Then you can use Bazel to execute the bartest. Bazel will create a temporary directory (as a bit of sandboxing) and copy all declared files (+ directories) into it. Bazel will execute the provided Python binary and try set PYTHONPATH so that a import foo does work (notice the imports declaration above). This is the part where I think a ._pth alongside the script would be beneficial, because for every test invocation the paths will be different. And multiple tests may be executed in parallel (so a "global" ._pth does not cut it). Using a ._pth one could get around setting an environment variable. Now to simplify deployment I want to put an embeddable Python alongside Bazel and always tell it to use this one. With Embeddable, the only way I have to modify sys.path is to execute Python with -c or write an intermediate script. Both can then modify sys.path and then load bar.py. Obviously this is not as nice as having a direct command-line switch or ._pth mechanism available. I hope I explained enough. If not - don't hesitate to ask. -- ___ Python tracker <http://bugs.python.org/issue29503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29503] Make embedded-Python detectable
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 advocating for support for embeddable Python :). We should discuss whether we use -c or a wrapper script. The latter might be the better option on the long run for other reasons, too. My original question stems from the desire to only use e.g. a wrapper script for embeddable for the near future. Reason being that it is not yet as well tested as the PYTHONPATH approach. So would be hesitant to switch from PYTHONPATH to wrapper script for all variants. Also I am not sure yet, the wrapper script is an option for all cases. Thanks for the input. -- ___ Python tracker <http://bugs.python.org/issue29503> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
