conda-recipes | Miscellaneous recipes '' for the Conda packaging system | Portal library

Self-answer:

It was a bug in conda that was patched later on: https://github.com/conda/conda-build/issues/1967

Instead of the meta.yaml parsing Perl import test statements as Perl, it was parsing them as Python.

This has nothing to do with jupyter: that character, and the one on the other end of your string, is not an ASCII apostrophe:

I figured this out. Thanks to everyone who took the time to look over my question. There was truly no way that anyone could have figured this out for me, since it was rather specific to the package I was installing. I'm going to try to summarize what I've learned in case someone else runs into anything different.

1. First, as I noted in one of the comments, if you're specifying a specific version requirement under the build, you had better specify the same version requirement under run. Initially I had "python 3.6.*" specified under build, but just "python" under run. This caused the package to be named something ending with "-py27_0", since the package name, understandably, depends upon what's required to run it, not to build it.
2. The really tricky thing was to understand that there were additional requirements specified in the setup.py script that were being installed automatically when I ran "python setup.py install" by hand, but were not being run when I tried to build under conda. Once I added these requirements to the meta.yaml recipe, everything builds and tests fine.

So, the lessons are to be consistent with your conda requirements between build and run, and make sure you have all of the requirements listed, including bonus requirements that may be specified in the setup.py file.

Thanks again to all who looked at this.

Looks like when I ran conda build . it was installing the (test) library to the first path given by .libPaths(), which wasn't the path to the conda build environment. Setting .libPaths() to only refer to the active environment directory fixed this problem.