xoviat <xov...@gmail.com> added the comment:
Just to be clear, I'm not considering doing this with respect to the C/C++
runtimes, but all of the other shared libraries. And in case you weren't aware,
this is exactly what auditwheel does (except that I believe it uses patchelf,
whe
xoviat <xov...@gmail.com> added the comment:
For the record, moving the DLL path manipulation code into the interpreter
would address the concern that importing a module would not manipulate the
search path because the behavior would move into Python
xoviat <xov...@gmail.com> added the comment:
This is what ray said:
"Please do not do this. Importing a specific module should not modify the way
that process loads subsequent DLLs."
(https://github.com/numpy/numpy/pull/10229#issuecomment-354846459)
What I'm proposing to do
xoviat <xov...@gmail.com> added the comment:
As Nathaniel noted, the "solution" of placing DLLs in the same directory as
extension modules is not a solution. I also think that some people here
misunderstand my proposal: I'm not necessarily proposing that these directories
xoviat <xov...@gmail.com> added the comment:
My current plan is to patch the __init__ package files to add the '.libs'
folder to the search path. However, I think it would be better for Python to do
this so that there is a consistent mechanism for loading shared lib
xoviat <xov...@gmail.com> added the comment:
So the idea here is actually to write a replacement for auditwheel that works
on windows. In order to do that, I need to recursively analyze DLL
dependencies, randomize the DLL filenames, rewrite the pe header table, and
then cop
xoviat <xov...@gmail.com> added the comment:
Sorry, that should have read:
2. A folder two levels under site-packages that is named '.libs'
Please consult the auditwheel source to determine the specific pattern if there
is doubt.
--
___
New submission from xoviat <xov...@gmail.com>:
On linux and macOS, a mechanism exists to relocate shared libraries inside of a
wheel. Auditwheel creates a .libs folder and places the shared libraries inside
of it. The problem is that on Windows, the rpath mechanism doesn't exist.
New submission from xoviat <xov...@gmail.com>:
Yes, I know that this isn't Python's fault. I know how to resolve the problem.
But what's frustrating is that this error message is totally unhelpful, because
it doesn't contain the DLL that Python is looking for.
Yes, I know that the
xoviat <xov...@gmail.com> added the comment:
Unfortunately, this issue has taken on a much lower importance for me, and
as such, I won't be able to address it. Sorry about that.
2017-10-26 0:01 GMT-05:00 Berker Peksag <rep...@bugs.python.org>:
>
> Berker Peksag <berker.pe
xoviat added the comment:
@zooba
Since you mention it, I agree with that proposal. But currently we have core
developers contributing to distutils and @jaraco contributing to setuptools.
@jaraco is quite competent, but I doubt that he would be able to maintain an
independent fork
New submission from xoviat:
MSVC 2017 retains ABI compatibility with MSVC 2015, yet supports (as always
with a newer compiler version) more features and compiles faster. Because it
retains ABI compatibility with existing Python versions, I think it makes sense
for distutils to prefer
12 matches
Mail list logo
