[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 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 > <https://bugs.python.org/issue35173> > ___ > -- ___ Python tracker <https://bugs.python.org/issue35173> ___ ___ 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
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 <https://bugs.python.org/issue35173> ___ ___ 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
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 <https://bugs.python.org/issue35173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35172] Add support for other MSVC compiler versions to distutils. distutils makes two incorrect assumption that MSVC compiler versions scale linearly and that the crt's are the same.
New submission from Ali Rizvi-Santiago : Distutils makes a few incorrect assumptions that prevent it from supporting the newer Microsoft-y C compilers. This patch fixes it up till MSVC 14.0. There are 2 assumptions that are made by distutils and they are as follows. The first one is that MSVC's versions scale linearly (subtracting 6). This assumption breaks when encountering major version 13.0 as VS2013 (12.0) uses 1800 and VS2015 (14.0) uses 1900 and so the calculation for version 13.0 does not actually exist. This was fixed in the patch for both msvc9compiler.py and msvccompiler.py by skipping the major version 13. The second assumption is in the get_msvcr() function in cygwinccompiler.py and is responsible for identifying the CRT name. The newer versions of MSVC aren't listed, so these were added in the patch. However, for version 1900 (MSVC 14.0) the crt is now named "vcruntime140" which was included. It might be better to to make this table-based if there is long-term interest in supporting these other compilers. These are the only issues that I've ever encountered over the years with building CPython 2.7.x with the newer VS compilers. -- components: Distutils files: distutils.patch keywords: patch messages: 329321 nosy: Ali Rizvi-Santiago, dstufft, eric.araujo priority: normal severity: normal status: open title: Add support for other MSVC compiler versions to distutils. distutils makes two incorrect assumption that MSVC compiler versions scale linearly and that the crt's are the same. type: enhancement versions: Python 2.7 Added file: https://bugs.python.org/file47908/distutils.patch ___ Python tracker <https://bugs.python.org/issue35172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
