[Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

[Chris Barker]

On Fri, May 15, 2015 at 11:35 PM, David Cournapeau <cournape at gmail.com>
wrote:

> On Sat, May 16, 2015 at 4:56 AM, Chris Barker <chris.barker at noaa.gov>
> wrote:
>
>>
>> But in short -- I'm pretty sure there is a way, on all systems, to have a
>> standard way to build extension modules, combined with a standard way to
>> install shared libs, so that a lib can be shared among multiple packages.
>> So the question remains:
>>
>
> There is actually no way to do that on windows without modifying the
> interpreter somehow.
>

Darn.


> This was somehow discussed a bit at PyCon when talking about windows
> packaging:
>
>  1. the simple way to share DLLs across extensions is to put them in the
> %PATH%, but that's horrible.
>

yes -- that has to be off the table, period.


> 2. there are ways to put DLLs in a shared directory *not* in the %PATH%
> since at least windows XP SP2 and above, through the SetDllDirectory API.
>
> With 2., you still have the issue of DLL hell,
>

could you clarify a bit -- I thought that this could, at least, put a dir
on the search path that was specific to that python context. So it would
require cooperation among all the packages being used at once, but not get
tangled up with the rest of the system. but maybe I'm wrong here -- I have
no idea what the heck I'm doing with this!

which may be resolved through naming and activation contexts.
>

I guess that's what I mean by the above..


> I had a brief chat with Steve where he mentioned that this may be a
> solution, but he was not 100 % sure IIRC. The main drawback of this
> solution is that it won't work when inheriting virtual environments (as you
> can only set a single directory).
>

no relative paths here? or path that can be set at run time? or maybe I"m
missing what "inheriting virtual environments" means...


> FWIW, we are about to deploy 2. @ Enthought (where we control the python
> interpreter, so it is much easier for
>
us).
>

It'll be great to see how that works out, then. I take that this means that
for Canopy, you've decided that statically linking everything is NOT The
way to go. Which is a good data point to have.

Thanks for the update.

-Chris



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150516/32857039/attachment.html>