[Distutils] Wheels and dependent third party dlls on windows
Paul Moore
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"
>> directory...
>
> 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
put them.
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
it's unofficial.
Paul
More information about the Distutils-SIG
mailing list