ImportError: DLL load failed: The specified module could not be found.

Benjamin Bengort

13 Feb, 2019 01:50 AM

Hello,

Recently our builds started failing on https://ci.appveyor.com/project/districtdatalabs/yellowbrick in our Miniconda3-x64 matrix (though they pass on the vanilla Python builds). I don't believe we made any changes to our codebase that might have caused the builds to fail (the last few PRs have been primarily documentation related). The builds are failing with the following traceback:

This doesn't appear to be a problem with nltk, but rather with the python site-packages library sqlite3. We've googled around and found several related issues where there appears to be a stray DLL, which I believe is part of the image, and not part of our testing process:

Unfortunately, neither of these fixes worked. We've had to comment out miniconda from our build matrix which is less than ideal. If there is another solution, we'd appreciate it because testing against miniconda is critical to our workflow.

Hi Owen, sorry it's taken a while to respond. Yes - we do have a local build of miniconda that works, and the previous images worked. We do have a PR open that we're currently reviewing that may fix the install issues but causes our tests to break. Still, this is not an issue with our code base but is rather an install issue for one of our dependencies in the setup phase of the tests. We are also looking into conda-forge to do the install, but these seem like a lot of hoops to jump through for Python testing.

I forked your repo and after many partly random/partly educated guesses i got a successful build on the current VS 2017 image.
The relevant change is in the line,

- "SET PATH=%PYTHON%;%PYTHON%\Scripts;%PYTHON%\Library\bin;%PATH%"

in the install: stage.

Though, I'm frankly not well versed enough in Python module machinery to understand why this is necessary and still confused as to how this is working on your local machine. It's difficult to imagine how the installation of miniconda on our build VMs could be faulty.

If it is a path issue, then I think it's more about how the image installs conda/pip -- with a local install that is handled once when you start working and then you don't think about it again. In this case, my guess is that the installer couldn't find a module because it was installed in a location on the $PATH that didn't match the modules being found? Did the path or the install location change during the image revision?

No changes to the install path of miniconda were made in either image updates.
The version of miniconda changed on this platform update. That initially broke your build so you used previous as a temporary workaround until another platform update made the "previous" image the newer one.
How do you know it's not the newer version of miniconda that causes this failure?

I suggest that you RDP to the build machine to investigate, and let us know what your idea of what is wrong with the build image is.