[issue29503] Make embedded-Python detectable

Changes by Steve Dower : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue29503] Make embedded-Python detectable

Steve Dower added the comment: You can also use the nuget packages (search on nuget.org for Python). These are intended to be used is scripted standalone setups, such as CI systems. I've been using them as part of most of my build systems recently. They support distutils and pip (not venv in

[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

[issue29503] Make embedded-Python detectable

Paul Moore added the comment: OK, well I certainly wouldn't bother supporting users trying to provide the path to an embedded distribution of Python. That's not what the distribution is for, and as the author of Bazel you'd be perfectly OK (IMO) to say you don't support that. If you want to

[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 =

[issue29503] Make embedded-Python detectable

Paul Moore added the comment: I'm still not clear what you're doing here - why does it matter where you have the _pth file? Could you explain how your application directory is laid out, and what is the main executable for the application? I'm assuming it's a Windows executable, myapp.exe,

[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

[issue29503] Make embedded-Python detectable

Paul Moore added the comment: With the embedded distribution, you should probably be calling the Python API rather than running python.exe. And if you do it that way, you can set sys.path via the API before calling user code. Alternatively, you can set up a site.py within your copy of the

[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

[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

[issue29503] Make embedded-Python detectable

R. David Murray added the comment: Why should a library behave differently if the python using it is embedded in an application? Can you explain your use case in more detail? -- nosy: +r.david.murray ___ Python tracker

[issue29503] Make embedded-Python detectable

Paul Moore added the comment: The embedded distribution is meant to be for just that - embedded applications. I'm not quite sure what you mean by support it, or when you would write code that needed to know it was being run from an embedded application. Can you clarify precisely why you need

[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