A good overview on this topic is given on https://github.com/numpy/numpy/wiki/windows-dll-notes. As a side note the PATH is usually the latest place in the search order of DLLs. Pre-loading python35.dll into the process space from within vim could be a possible solution. 2015-09-09 16:30 GMT+02:00 Paul Moore <p.f.moore at gmail.com>: > First of all, an apology. I know this is probably going to be of > limited interest for many on python-dev, but I'm honestly not sure > where there's a better audience for the question. As it's related to > how people should use the new "embeddable" distribution of Python 3.5, > I'm hoping it's sufficiently relevant - but if not, feel free to > direct me to a better forum. > > I've been trying to use the new embeddable distribution to build a > Windows installation of vim that includes a Python interpreter, rather > than relying on the user having a system install of Python on PATH. > This strikes me as precisely the sort of usage that the embeddable > distribution would be great for. And indeed, it works fine for that. > But when it comes to distribution, I have an issue. > > The problem is that for vim to find the Python DLL, it needs to be > alongside vim.exe (there's a small complication here I'll come to > later, but let's ignore that for now). So I unzip the embeddable > distribution into the directory containing vim.exe. > > However, I want that directory on PATH (so I can run vim from the > command line). Now, as the embeddable distribution includes > python.exe, this pollutes my PATH with an extra copy of python, which > may or may not be picked up in preference to my "real" python, > depending on how I install python. That's bad - I can delete > python.exe and pythonw.exe from my vim installation, but I still have > a load of Python DLLs on PATH that could potentially mess up other > Python installations on my machine (I honestly don't know how likely > that is, particularly if I distribute my vim build to other users with > different setups). > > What I'd like to do is to put the Python stuff in a subdirectory of > the Vim installation, so it's safely isolated. In the case of vim, I > can do this, as vim has an option to dynamically load the Python DLL > via LoadLibrary, and I can patch vim to look in <vim dir>\python > before searching PATH. But the LoadLibrary stuff is horribly fragile, > and I doubt anyone else embedding Pthon in their application is likely > to do that - they will probably just link to python35.dll at > load-time. > > I'm not aware of any way to adjust the loader's search path for DLLs > to include a subdirectory that's not on PATH, so it seems to me that > there's no good way to avoid having the embeddable distribution > visible via the user's PATH. > > For vim, I'll probably go for the dynamic loading approach with a > patch to look in a subdirectory. But have I missed any other > approaches that make an embedded Python more isolated from the user's > system? > > Paul > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150909/75a6caa1/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4