[Distutils] Wheels and dependent third party dlls on windows
p.f.moore at gmail.com
Thu Oct 2 01:16:46 CEST 2014
On 1 October 2014 23:10, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> Sorry, you're right. But the legacy (non entry-point) scripts are
>> certainly fragile, and I'd recommend avoiding them. Even for actual
>> scripts, and *certainly* as a hack to get things in the "Scripts"
> Note that PEP 459 currently proposes preserving this capability as
> "python.commands.prebuilt", so I personally consider it reasonable as a way
> of packaging arbitrary executables and non-entry-point based scripts.
Existing code tends to try to rewrite shebang lines on scripts. And
maybe on Unix add the executable bit. The wheel spec (installing a
wheel, the "Spread" step, item c) actually requires that script
rewriting is done, so in theory that makes the scripts subdirectory in
a wheel unsuitable. In practice of course, DLLs will be fine as they
don't start with #!python.
The "python.commands.prebuilt" spec doesn't say whether #! rewrites
are done. If they are, they have the same issue as scripts. If they
aren't, the current wheel spec doesn't offer an appropriate area to
Basically, it needs a wheel spec update to have an area which holds
files that are copied unchanged to the destination Scripts folder.
But this is entirely standards-style nitpicking. The existing scripts
support is fine for DLLs, and will work as expected for every
practical purpose. That's why I called it a "hack" - it works, but
More information about the Distutils-SIG