I feel like this is a common argument, but a bit disingenuous. One of the major reasons venvs are more complex and less portable than node_modules is it's fairly rare for node to bind to c/c++, but very very common for python to do so.

conda solves that for python at least as well as npm/yarn does. I don't understand while it is not in wider use (except for lack of PR).

If you want to add your own project to Conda, you need to use conda forge, because Anaconda itself is a curated distribution.

Maintaining a conda forge package has been, for us, a complete nightmare. If you depend on another conda-forge package you can have the issue that the library is configured to suit whoever first wrote the conda-forge package - i.e. by disabling parallelism or providing only shared/static libraries, and have that maintainer be completely unresponsive or unwilling to change it.

That is a downside of community maintenance, for sure. Conda-forge probably needs official policies and suggested workflows to have multiple varieties of recipes where feasible. There is never a one-size-fits-all solution when a community serves so many different people with so many different use cases. Spack fits the "my way and only my way" mentality better. Conda is more "close enough, and already ready for me to use."

If you let us know about the package, we can work with you to create a variant.

conda / miniconda has definitely solved most of my grievances with deploying python applications

how does conda solve this? Will conda fallback to pip if the conda repository doesn't contain one of your dependencies?

With your conda environment activated, you can run pip install requirements.txt. You don't have to use any of the conda commands outside of creating the environment.

What is wrong with virtualenv, pip and pip freeze?

They work, but there's much more friction and many more gotchas than node. The requirements file for example, doesn't distinguish between direct and ancestor dependencies, it has to be explicitly passed to pip, you need to have created and activated your virtual environment correctly, many python libs have fragile, c based builds. Node and nvm just work.

I use separate requirements-to-freeze.txt and requirements.txt, so that I maintain only list of direct dependencies (no transitive dependencies) and only pin versions when I know the code won't work with the latest version, but pip freeze creates a file like package lock with all the dependencies versioned so I can recreate the exact environment again without needing to store a docker image of it or something like that. See https://www.kennethreitz.org/essays/a-better-pip-workflow

Needing to name the requirements file and needing to activate venv are not pain points I feel.

Wrapping native libraries and not invoking a C compiler at package install time means some trade-offs. https://cffi.readthedocs.io/en/latest/cdef.html