`pyimport_conda` doesn't seem to handle superseded packages correction.

[rofinn]

Recently the main conda channel added keras-2.2.4, but some of our internal legacy code requires 1.2.2. As a result, we've been getting this superseded notice:

The following packages will be SUPERSEDED by a higher-priority channel:

  keras                            pkgs/main::keras-2.2.4-0 --> conda-forge::keras-1.2.2-py27_0

Normally this isn't an issue, but it pyimport_conda doesn't seem to finding the downgraded version:

) <type 'exceptions.ImportError'>
ImportError('cannot import name activity_l1l2',)
  File "/root/.julia/v0.6/Conda/deps/usr/lib/python2.7/site-packages/private-package/__init__.py", line 15, in <module>
    from private-package.main import run
  File "/root/.julia/v0.6/Conda/deps/usr/lib/python2.7/site-packages/private-package/main.py", line 7, in <module>
...
    from keras.regularizers import activity_l1l2    # l1l2 for weight regularization

It seems that simply re-loading the package that's using pyimport_conda in the __init__ resolves the issue.

[rofinn]

I'll note that explicitly adding Conda.add("keras==1.2.2") to deps/build.jl also resolves this problem.

[tkf]

I think pyimport_conda has some inherent problems in design (including this one). I've been suggesting to move to build-time installation: #613.

Also, for case like this, resurrecting Conda.pin from https://github.com/JuliaPy/Conda.jl/pull/129/files#diff-b5a035973669724cfc435a3914eae6ebR299 sounds like a good addition.

[rofinn]

Looks like pyimport_conda("keras", "keras==1.2.2") also worked. I wish using a specific version was the equivalent to pinning in base conda.

[tkf]

I think specifying conda package version in pyimport_conda works only if Python throws error at import time. This seems to be the case here, but I can imagine the case that the Python package has some updates only in (say) call signature so that import succeeds. If this happens, you can't re-install it via pyimport_conda.