On Tue, Sep 30, 2014 at 7:45 AM, Daniel Holth <dholth@gmail.com> wrote:
Or you could just create a Python package that only contains the dll,
and depend on it from your others.

but it won't be on the dll search path. 
Paul Moore wrote:
What you could do is distribute a package containing:
1. The dll
2. An __init__.py that adds the package directory (where the DLL is)
to os.environ['PATH'].
If you import this package before any of the ones that depend on the
DLL (or even in the __init__ of those packages) then you should have
PATH set up correctly, and things will work as you need.
I think this works, although I will admit it feels like a bit of a hack to me.

I'm not sure it will -- I tried somethign similar -- where I compiled some code into an extension, hoping that importing that extension would make that code available to other extensions -- works fine on OS-X and Linux, but no dice on Windows.

So we build a dll of the code we need to share, and link all the extensions that need it to it. In our case, all the extensions are part of the same package, so we can put the dll in with the extensions and we're set.

It seems the "right" thing to do here is put the dll in with the dlls provided by python (can't remember that path right now -- no Windows box running) -- but I don't know that you can do that with wheel -- and it would make it easy for different packages to stomp on each-other.

I actually think the thing to do here is either statically link it to each extension that needs it, or deliver it with each of them, in the package dir. Or, if you don't want duplicates, then use conda -- it's designed just for this.

I'd also look at what Chris Gohlke does with his MSI installers:

maybe he's doing something you can do with MSI that you can't do with wheels, but worth a look.


Christopher Barker, Ph.D.

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