Conda now supports PyPy builds
conda-forge.org
conda-forge.org
Then I discovered pyenv + virtualenv. I can't think of a single issue over the last 18 months. I can easily run any version of Python, virtual environments are way easier to deal with, and PIP has been so much better than conda for packages.
Is there something else I'm missing about conda? Or was conda something that was needed and great several years ago, but not so much these days?
I'd also love to hear if there's something better than pyenv + virtualenv I should look into.
However, one of the main benefits I remember is that it is not just Python env/package mgmt. Data scientists can pull R packages too.
I take Anaconda at their word that they are a different distribution of Python and conda is a tool to manage Anaconda environments, which includes more than just Python. I find it difficult to completely trust them as a for-profit company that is putting itself between Python programmers and the actual community package repos. I don't think there is any particular advantage to Conda unless you are support the use cases I described above, but good people disagree sincerely on it.
That alone makes it very, very worth it.
If you go the route of Virtualenvwrapper (over just virtualenv), just make sure you install the Pyenv plugin version, as plain standalone virtualenvwrapper has annoying path issues that don't work well with Pyenv.
> Is there something else I'm missing about conda?
Yes. You missed pip working perfectly well inside conda since day 1 (and integration is getting better). In the past, pip did not participate in conda dependency resolution (and I think it still doesn't, at least not perfectly). But it's not worse than using pip outside conda; and when you DO have a conda package, it is usually more dependable.
> I can easily run any version of Python, virtual environments are way easier to deal with, and PIP has been so much better than conda for packages.
Can you run the latest Python 3.8 on your old extended-support Ubuntu Server 14.4 that you can't upgrade because reasons, on pyenv+virtualenv? Genuinely asking; you can with conda.
Definitely. If Python 3.8 isn't available from the package repository for ubuntu 14.04 you'll need to install it some other way -- either from source or from a binary package someone else compiled -- after which you can simply
python3.8 -m venv venv
Of course anaconda provides python binaries itself which is mighty convenient but it's not like it's the only way to tackle the problem.
Anyway, conda isn't really aimed at either of these scenarios. It's aimed at people doing research, data science, etc, where you are likely to use a sprawling assortment of packages, many of bewildering complexity, and entirely without the time to tinker with which package version works with which.
The naive algorithm that pip use, which essentially is to grab the latest version of everything often doesn't cut it in these scenarios. Conda, with all it's warts, actually does dependency resolution, which it's why it's so much "slower", it does something completely different from pip.
As pip and conda can coexist today, I simply install what's not available in conda/conda-forge with pip, and have a much easier time manage all my dependencies.
If you do anything in data science, or similar, it's rarely a problem that things doesn't exist in conda, because they almost always do, which is not the case with all kinds of packages.
That might be down to which sorts of packages you're using. By far most projects I work on pip does entirely fine without manually specifying versions. I have rarely ran into version conflicts and when I have it's usually resolved by pinning a single package version.
The thing where I really see people trip with pip is when a package requires compiling a C module. Pip somewhat silently assumes you've got a working C compiler and all header files for the package. The error messages here are confusing and unhelpful for most python programmers. The whole push towards universal wheels is alleviating this problem but the current state of things is suboptimal.
Add to that the whole confusing state of creating python packages in general and you get a nice mix of dysfunctional packages and packages that'd work with the right headers. None of this is really pips fault and anaconda doesn't fix all of these issues either.
In my experience pip is mostly just harder to get started with but is afterwards a much better solution simply because pip doesn't hide anything from you which is a great boon when debugging packaging issues.
If you are primarily python but need to add C/C++/BLAS/LAPACK/MKL/Fortran, etc..., at least on linux and macOS, then you are going to want conda or something like it. conda with the conda-forge channel solves much of that.
There's other things out there which can solve it, notably Spack, possibly Nix. Or, you reduce the problem space by only building for a single linux and distributing containers, if that works for you.
This is conda forge, which is very popular but it is not conda.
That said, I won’t be entirely surprised if there is a fork in the next 1-3 years, with conda-forge releasing miniforge.
Conda can in fact install pypy from conda-forge, which is close enough for most people.
It's making sure each package has transitive dependencies that behaves well on pypy.
This is a huge effort.