On Fri, May 15, 2015 at 11:35 PM, David Cournapeau <courn...@gmail.com> wrote:
> On Sat, May 16, 2015 at 4:56 AM, Chris Barker <chris.bar...@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.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
