From conda create requirements.txt for pip3

In a conda environment with simply calling

pip freeze

I got:

ipykernel @ file:///C:/ci/ipykernel_1607454116140/work/dist/ipykernel-5.3.4-py3-none-any.whl
ipython @ file:///D:/bld/ipython_1612487184680/work
...

Wanted format:

ipykernel==5.3.4
ipython==7.20.0
...

In an activated conda environment I had to use

pip list --format=freeze

to get the correct format for generating a requirements file for people who prefer to use pip with virtual environments.

As the comment at the top indicates, the output of

conda list -e > requirements.txt

can be used to create a conda virtual environment with

conda create --name <env> --file requirements.txt

but this output isn't in the right format for pip.

If you want a file which you can use to create a pip virtual environment (i.e. a requirements.txt in the right format) you can install pip within the conda environment, then use pip to create requirements.txt.

conda activate <env>
conda install pip
pip freeze > requirements.txt

Then use the resulting requirements.txt to create a pip virtual environment:

python3 -m venv env
source env/bin/activate
pip install -r requirements.txt

When I tested this, the packages weren't identical across the outputs (pip included fewer packages) but it was sufficient to set up a functional environment.

For those getting odd path references in requirements.txt, use:

pip list --format=freeze > requirements.txt

Following the discussion, I'd like to mention that you can actually see some separation of pip and conda roles.

pip is a standard package manager, it does one thing and does it well. requirements.txt can be generated in one environment and installed by pip in a new environment.

Now there is conda output: you rightfully capture their comment which says 'we generated this list of libraries to work with conda'. Note that python itself is in the conda list and (properly) not in requirements.txt. conda replicates own installation, that is why its list of libraries is longer, and has python itself.

pip produces a list of packages that were installed on top of standard library to make the package you wrote work. Hope it helps to distinguish between the two.

Also pipenv is a newer tool, that can do both virtual environment and package management for you.