undefined symbol error installing pynio & matplotlib

[maddenp]

I'm not actually sure that the problem is with this package, but thought I would start here and ask for guidance. I have a set of packages that, when installed together, lead to the following behavior:

(foo) ~/git/so % python -c 'import Nio'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/pm/miniconda/envs/foo/lib/python2.7/site-packages/PyNIO/Nio.py", line 83, in <module>
    from nio import *
ImportError: /home/pm/miniconda/envs/foo/lib/python2.7/site-packages/PyNIO/../../../libgdal.so.20: undefined symbol: _ZN6kmldom5ParseERKSsPSs

I kept removing things from the set of packages until I found this seemingly minimal reproducer:

conda create -n foo -c conda-forge -c defaults pynio matplotlib=2.1.0

If you create and activate that environment, I think you'll encounter the same error with import Nio. (Actual versions/builds in my environment are pynio=1.5.0=py27_1 and matplotlib=2.1.0=py27_1.)

Since the resolver seems to be ok with this recipe, it seems like something is wrong. But maybe the problem is with matplotlib... I'm not sure how to take the next step in diagnosis.

[ocefpaf]

https://github.com/conda-forge/libgdal-feedstock/pull/33 should fix this.

[ocefpaf]

Should be OK now.

[maddenp]

I get a different error now:

% conda clean --all --yes
% conda create -n foo -c conda-forge -c defaults pynio matplotlib=2.1.0 --yes
% source activate foo
(foo) % python -c 'import Nio'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/media/pmadden/o/miniconda/envs/foo/lib/python2.7/site-packages/PyNIO/Nio.py", line 83, in <module>
    from nio import *
ImportError: libicui18n.so.56: cannot open shared object file: No such file or directory

Should I open a separate ticket?

Thanks for your tireless efforts supporting conda-forge.

[ocefpaf]

Try without the -c defaults, see this for more info on why, and without pinning matplotlib. Matplotlib 2.1.0 was built with dependencies that are no longer supported and we won't rebuild them. mpl 2.1.2 should work for you there.

[maddenp]

I unpinned my larger list of meta.yaml run-requirement packages and conda resolved a set that passed my regression tests, so I'm good now. Thank you.

I'm curious about your "without the -c defaults" advice, though. I know it wasn't clear from my example, but I normally use -c conda-forge -c defaults --override-channels in my builds, for reproducibility. Now, --override-channels was broken for quite a while, but I believe it's supposed to be fixed now, and I want to use it to insulate my users from anything that might be present in their ~/.condarc file. According to the docs, --override-channels means

Do not search default or .condarc channels.

Don't some conda-forge packages depend on defaults packages? I seem to always get them in my package lists, even when I specify -c conda-forge first (or only). If so, I assume that (if --override-channels works as advertised) I must include -c defaults. Is that not true?

[ocefpaf]

and I want to use it to insulate my users from anything that might be present in their ~/.condarc file. According to the docs, --override-channels means

OK. That is a nice idea.

Don't some conda-forge packages depend on defaults packages?

Yep. In some cases we do.

Don't some conda-forge packages depend on defaults packages? I seem to always get them in my package lists, even when I specify -c conda-forge first (or only). If so, I assume that (if --override-channels works as advertised) I must include -c defaults. Is that not true?

You are correct. What I don't know is if channel order is preserved when you do that, but if your tests are OK I guess it is.

[maddenp]

I had a good discussion with conda-build's @msarahan about this here. He cited evidence that the channel order from the command line should be respected, but I haven't had time to test that since --override-defaults was reportedly fixed (and the question was moot before that). But, as you say, maybe my passing tests are evidence (proof?) that it does work.