On 09Sep2015 0819, Paul Moore wrote: > On 9 September 2015 at 16:11, Carl Kleffner <cmkleffner at gmail.com> wrote: >> 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. > > Thank you for this. From a very quick read, it looks like I could put > the embedded Python files in a directory ...\gvim.exe.local. I'll give > that a try (there's a downside, in that I'd need a duplicate copy in > ...\vim.exe.local if I wanted the console version to work too). It > looks like SxS assemblies might help too, but that'll need a bit more > reading before I understand it :-) Don't bother reading into SxS assemblies. It may work, but it will destroy more brain cells than are worth wasting on it. :) Certainly putting the distro into a subdirectory is what I had expected would be common. In general, putting application directories in PATH is considered poor form, but unfortunately we don't have a better approach (there are App Paths, but those only work via the shell). Another approach you could use is making a separate directory to put on PATH that contains stub executables (or symlinks?) to launch the actual ones from a separate directory. That way you can control exactly what is available on PATH while still launching from a directory that is not on PATH. Cheers, Steve > Paul
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