What to do when pip & conda overlap?

The Tensorflow maintainers actually publish the wheels of TensorFlow on PyPI that's why it's the recommended official way. The conda packages are created by the Anaconda staff and/or the community. That doesn't mean the conda packages are bad, it just means that the TensorFlow maintainers don't participate there (officially). Basically they are just saying: "If you have trouble installing it with pip the TensorFlow devs will try to help you. But we don't officially support the conda packages so if something goes wrong with the conda package you need to ask the conda-package maintainers. You've been warned."

In the more general case:

For Python-only packages you should always use conda install. There might be exceptions, for example if there is no conda-package at all or the conda package is out-of-date (and nobody is releasing a new version of that package) and you really need that package/version.

However it's different for packages that require compilation (e.g. C-Extensions, etc.). It's different because with pip you can install a package either:

• as pre-compiled wheel
• as package, compiled on your computer

While conda just provides the

• compiled conda package

With compiled packages you have to be careful with binary compatibility. That means that a package is compiled against specific binary interface of another library - which could depend on the version of the libraries or the compilation flags, etc.

With conda you have to take the package as-is, which means that you have to assume that the packages are binary-compatible. If they aren't it won't work (segfault or linking errors or whatever).

If you use pip and can choose which wheel (if any) to install or compile it against the available libraries on your computer. That means it's less likely that you get a binary-incompatibility. That is (or was) a big problem if you install conda packages from different conda-channels. Because they might simply be binary-incompatible (e.g. conda-forge and the anaconda-channel have or had a few problems there).

However it should probably be decided on a case-by-case basis. I had no problems with my tensorflow conda environment where I installed all packages from the conda-forge channel, including tensorflow. However I have heard that several people had trouble with tensorflow in mixed conda-forge and anaconda channel environments. For example NumPy from the main channel and TensorFlow from the conda-forge channel might just be binary-incompatible.

My rule of thumb is:

• If it's a Python-only package just install it (it's unlikely to make trouble). Use the conda package when possible but it won't make (much) trouble if you use pip. If you install it using pip it's not managed by conda so it's possible it won't be recognized as available dependency and you have to update it yourself, but that's about all the difference.
• If it's a compiled package (like a C extension or a wrapper around a C library or such like) it becomes a bit more complicated. If you want to be "careful" or you have reason to expect problems:
• Always create a new environment if you need to test compiled packages from different channels and/or conda and pip. It's easy to discard a messed up conda environment but it's a lot more annoying to fix an environment that you depend on.
• If possible install all compiled packages using conda install from one and only one channel (if possible the main anaconda channel).
• If not possible try to mix main anaconda channel compiled packages with conda packages from a different channel.
• If that doesn't work try to mix conda compiled packages and pip compiled-packages (pre-compiled wheels or self-compiled installers).

You asked about why you cannot install packages from PyPI with conda. I don't know the exact reasons but pip mostly provides the package and you have to install it yourself. With conda you get an already compiled and installed package that is just "copied" without installation. That requires that the package is installed on different operating systems (Mac, Windows, Linux) and on platforms (32-bit, 64-bit), against different Python versions (2.7, 3.5, 3.6) and possibly against different NumPy versions. That means conda has to provide several packages instead of just one. That takes resources (space for the final installed packages and time for the installation) which probably aren't available or feasible. Aside from that there is probably no converter for a pypi package to a conda recipe aside from all the specifics you have to know about a package (compilation, installation) to make it work. That's just my guess though.