[issue35173] Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path according to the shared library

[Ali Rizvi-Santiago]

Ali Rizvi-Santiago  added the comment:

Sure. It was for Python2 anyways.

-Ali

On Wed, Sep 25, 2019 at 8:00 PM STINNER Victor 
wrote:

>
> STINNER Victor  added the comment:
>
> Modules/getpath.c and PC/getpathp.c have been deeply reworked with the
> implementation of the PEP 587 in Python 3.8. Parameters which are already
> set (ex: Py_SetProgramName() or using the new PyConfig API) are no longer
> overriden. I added some tests on the "path configuration".
>
> The most reliable way to configure the path configuration is now to use
> the new initialization API using PyConfig.
> https://docs.python.org/dev/c-api/init_config.html
>
> --
> nosy: +vstinner
> resolution:  -> fixed
> stage:  -> resolved
> status: open -> closed
> versions: +Python 3.8, Python 3.9 -Python 2.7
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35173] Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path according to the shared library

[STINNER Victor]

STINNER Victor  added the comment:

Modules/getpath.c and PC/getpathp.c have been deeply reworked with the 
implementation of the PEP 587 in Python 3.8. Parameters which are already set 
(ex: Py_SetProgramName() or using the new PyConfig API) are no longer 
overriden. I added some tests on the "path configuration".

The most reliable way to configure the path configuration is now to use the new 
initialization API using PyConfig.
https://docs.python.org/dev/c-api/init_config.html

--
nosy: +vstinner
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9 -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35173] Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path according to the shared library

[Ali Rizvi-Santiago]

Change by Ali Rizvi-Santiago :


--
title: Re-use already existing functionality to allow Python 2.7.x (both 
embedded and standalone) to locate the module path -> Re-use already existing 
functionality to allow Python 2.7.x (both embedded and standalone) to locate 
the module path according to the shared library

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35173] Re-use already existing functionality to allow Python 2.7.x (both embedded and standalone) to locate the module path

[Ali Rizvi-Santiago]

New submission from Ali Rizvi-Santiago :

This is specific to the Windows platform as it's the only platform that uses 
the registry and other path hacks to identify the default module path. This 
patch is mostly intended for embedded Python, but is also applicable to a 
stand-alone Python.

A few years ago, I was looking at relocating my Python interpreter so that an 
embedded application (that I didn't have control over) would use the correct 
module path. While merging my code into CPython, I quickly noticed that Python 
already supported doing this with Py_ENABLE_SHARED but due to the 
implementation wasn't actually using it for some reason. The code that 
implements this is 10+ years old, so perhaps it was just an oversight or some 
other reason that I didn't know about.

Inside PC/getpathp.c there's a static variable, "dllpath", that is initialized 
with the path to the DLL that is being dynamically loaded when Py_ENABLE_SHARED 
is specified. Normally arg0 is used to locate the module path, but when 
embedding Python the .exe and thus arg0 is not involved. So, this patch uses 
"dllpath" by adding a final case to the calculation of the path by assigning it 
to "pythonhome" if the home was not able to be determined by any other means. 
This is done in 2 places within "calculatepath()".

This allows one to have multiple versions of Python (32-bit, 64-bit, older 
versions, etc) on the same Windows system and so a user should not need to copy 
the Python library into their System path or explicitly set any environment 
variables (unless truly desired of course). This should greatly simplify 
relocation of Python as the DLL and executable can be moved around without 
being dependant on any external invariants.

--
components: Interpreter Core
files: relocate-with-dllpath.patch
keywords: patch
messages: 329322
nosy: Ali Rizvi-Santiago
priority: normal
severity: normal
status: open
title: Re-use already existing functionality to allow Python 2.7.x (both 
embedded and standalone) to locate the module path
type: enhancement
versions: Python 2.7
Added file: https://bugs.python.org/file47909/relocate-with-dllpath.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com