Hi Evelyn,
You're running into a set of issues that are becoming increasingly more frequent. When I first encountered this, frankly my colleagues didn't believe me – but now it's become a tangible risk.
In fact, the first draft of this article contained an extra two pages about how to workaround installation errors for these libraries, although we decided to tear that part out and provide a condensed version in the GitHub repo https://github.com/DerwenAI/ibm_dsc_articles/blob/master/2020_05/INSTALL.md
There are a few issues interacting here.
First, what's your OS? Frankly, both Apple macOS and Microsoft Windows have backed themselves into a corner: they can't decide whether they are consumer products or operating systems. The former tends to be pre-packaged and proscriptive about what a user can install. The latter tends to support reliable use of compilers by a technical audience (like us) so that we download and compile open source.
At this point, I've used Macs since 1985, although I wouldn't bet on Apple's long-term viability unless they can move past the intense tech debt they've accumulated as a platform. But I digress.
The installers `conda` and `pip` represent radically different areas of software utilities, although they share the common ground of installing Python libraries.
On the one hand, PyPi and `pip` have problems, which have accelerated with later versions of Python. There's the notorious `ERROR: Could not build wheels for <some required libraries> which use PEP 517 and cannot be installed directly` issue that's become increasingly common. It's a deal breaker.
Some notable leaders within the Python community would love to wipe out use of "wheels" because of this, for example https://twitter.com/wesmckinn/status/1148350953793490944
On the other hand, increasingly `conda` tends to fail with its infinite loop of `Solving environment: failed with ...` mode. I've tested this and it'll keep running, days later still failing with the same issue.
Also, `conda` is not supported much these days. It has major structural problems. Anyone who's in a leadership role in the Python community and who's recommending that people only use `conda` is doing a disservice to the community.
Some popular open source libraries (e.g., RAPIDS) can only be installed through `conda` while others (e.g., Ray) can only be installed using `pip` – and quite candidly I detest both of those notions, although I collaborate with both of those respective teams.
Also, *many* open source teams tend to "bloat" their dependencies but meanwhile turn a blind eye to these kinds of installation issues. Sort of the "Hey, that's not my problem" flavor of ethics.
There are definitely people who'll rush to suggest using Docker, Kubernetes, etc., as a workaround. It's true that some libraries can be packaged effectively with Docker Compose, although that's not a general solution when your application must combine use of *many* different libraries.
What I suggest: if possible, use Ubuntu or another Linux, either locally on your laptop/desktop or by running a cloud instance. Use `conda` to create a "base" environment, then only install the minimum of libraries that `conda` can install reliably. Then use `pip` over the top of that base to install the remaining dependencies.
Some of the more mindful open source teams are cognizant of these problems and so you'll see `environment.yml` files which implement the approach described above: `conda` base, `pip` over the top.
For other libraries where the developers are less woke, you might try installing their problematic libraries first – manually. That's what the `INSTALL.md` instructions describe.
Hope that helps!