0

I followed the instructions here: Can't find package on Anaconda Navigator. What to do next?

I clicked Open terminal from environment on Anaconda navigator, and then used "pip3 install lmfit" in the terminal. But after installing the lmfit package using pip3, I still cannot find it in the conda list. What should I do?

Haoya Li
  • 13
  • 2

2 Answers2

0

The Problem

At the time of this question, Conda builds of pip had only just started including a pip3 entrypoint,1 therefore pip3 is very likely referring to a non-Conda version of Python and that is where the package was installed. Try checking which pip3 to find out where it went.

Recommendation

Conda First

Generally, it is preferable to use Conda to install packages in Conda environments, and in this case the package is available via the Conda Forge channel:

conda install -c conda-forge lmfit

Contrary to M. Newville's answer, this recommendation to prefer Conda packages is not about benefiting Conda developers, but instead a rule of thumb to help users avoid creating unstable or unreproducible environments. More info about the risks of mixing pip install and conda install can be found in the post "Using Pip in a Conda Environment".

Nevertheless, the comment that not all packages (and specifically lmfit) are found in the default repository and this complicates installation by requiring resorting to third-party channels is a good point. In fact, because third-parties are free to use different build stacks there are known problems with mixing packages built by Anaconda and those from Conda Forge. However, these issues tend to be rare and limited to compiled code. Additionally, adding trusted channels to a configuration and setting channel priorities heuristically solves the issue.

As for risks in using third-party channels, arbitrary Anaconda Cloud user channels are risky: one should only source packages from channels you trust (just like anything else one installs). Conda Forge in particular is well-reputed and all feedstocks are freely available on GitHub. Moreover, many Python package builds on Conda Forge are simply wrappers around the PyPI build of the package.

PyPI Last

Sometimes it isn't possible to avoid using PyPI. When one must resort to installing from PyPI, it is better practice to use the pip entrypoint from an activate environment, rather than pip3, since only some Conda builds of pip include pip3. For example,

conda activate my_env
pip install lmfit

Again, following the recommendations in "Using Pip in a Conda Environment", one should operate under the assumption that any subsequent calls to conda (install|upgrade|remove) in the environment could have undefined behavior.

PyPI Only

For the sake of completeness, I will note that a stable way of using Conda that is consistent with the recommendations is to limit Conda to the role of environment creation and use pip for all package installation.

This strategy is perhaps the least burden on the Python-only user, who doesn't want to deal with things like finding the Conda-equivalent package name or searching non-default channels. However, its applicability seems limited to Python-only environments, since other libraries may still need to resort to conda install.

[1]: Conda Forge and Anaconda started consistently including pip3 entrypoints for the pip module after version 20.2.

merv
  • 67,214
  • 13
  • 180
  • 245
  • This notion that "conda first" is preferable is entirely sold by the conda developers, mostly to benefit a commercial endeavor. That is fine, but it should be recognized for what it is. To say that `conda install PACKAGE` should always be preferred assumes that a) `conda` and `pip` have different dependency resolutions and b) that `conda` is "more correct" than `pip`. With complex binary dependencies, `conda` is certainly better. For properly configured **pure python** packages, it is simply untrue that `conda` is better, no matter how many times this is repeated. – M Newville Jun 04 '21 at 19:45
  • "However, these issues tend to be rare" needs a citation, with data. – M Newville Jun 04 '21 at 19:46
0

Installing a pure Python package, such as lmfit with the correct version of pip install lmfit should be fine.

Conda first is recommended to make the life of the conda maintainers and packagers easier, not the user's life. FWIW, I maintain both kinds of packages, and there is no reason to recommend conda install lmfit over pip install lmfit.

In fact, lmfit is not in the default anaconda repository so that installing it requires going to a third-party conda channel such as conda-forge. That adds complexity and risk to your conda environment.

Really, pip install lmfit should be fine.

M Newville
  • 7,486
  • 2
  • 16
  • 29
  • Thank you. It is very helpful. – Haoya Li Jun 19 '20 at 21:49
  • I downvoted because the claim that a "Conda first" recommendation is only to benefit Conda package developers is false. Rather, repeatedly mixing `pip install` and `conda install` can lead to unstable/unreproducible environments (see ["*Using Pip in a Conda Environment*"](https://www.anaconda.com/blog/using-pip-in-a-conda-environment), something that very much impacts end users. Your other comments are fair and valuable, so I would happily upvote were the false claim redressed. – merv Sep 26 '20 at 23:02
  • 1
    @merv I have read that guidance. I accept your downvote. As you say, problems can arise with `conda` when mixing channels, which is inevitable: conda-forge exists. For a **pure python** package, conda imposes Py version constraint and often imposes architecture constraint (`noarch` is not default), neither of which are actually needed. I experience more "false conda conflicts" than I do "unstable environments" from using pip to install **pure python** packages. So, "conda first" for pure python packages that are not in the default repo can cause much more pain than using pip. – M Newville Sep 27 '20 at 11:51