0

I'm currently running vanilla python 3.7.3 with a few packages installed that are commonly used. Our group manages our projects by creating a new environment with virtualenv (virtualenv name_of_env), building out a project and then exporting that environment to a requirements file which is shared with anyone in our group. The requirements files are then used to build ipykernels which are used in jupyter notebooks or building flask or dash apps.

I'm currently taking a class that wants us to use Anaconda and would like to create a virtualenv with the Anaconda base install packages. Is there anything like an "Anaconda requirements" file available that would allow me to install all the packages that the Anaconda base install uses without actually installing Anaconda?

As implied earlier, my ultimate goal is to create a virtual environment which I can use to build an ipykernel which can then be used for my class assignments without having to install Anaconda. I am aware that I can have multiple flavors or versions of python installed, but really don't want to do this unless it's necessary.

Michael Szczepaniak
  • 1,970
  • 26
  • 35
  • 1
    The poor man solution is running your code, getting import error, using pip install to solve that error and move to the next. In the end you'll have a working venv that you can freeze and save its requirements.txt file. – Pitto Dec 31 '19 at 19:49
  • Ya, but something a little more direct and less time consuming would really be cool. – Michael Szczepaniak Dec 31 '19 at 19:51
  • The key part here is having an environment that contains all the requirements for your software. Anaconda just simplifies (well, it is not that different from pip) this process but it is still a 100% per case scenario. Having Anaconda env doesn't mean that your software will run. If your software needs a module you will have to install that module using Anaconda and then use the software. It is not different from using Pip, in the end. – Pitto Dec 31 '19 at 20:01
  • Wait, I had an idea... – Pitto Dec 31 '19 at 20:04
  • Miniconda is really quite easy to uninstall if you don't like it. Unless youre worried about its security (and I consider the base packages safe), consider trying it and uninstalling it after your class. – Ben Dec 31 '19 at 20:08
  • If I understand [this](https://stackoverflow.com/questions/45421163/anaconda-vs-miniconda) link correctly, miniconda is just python, conda and the packages that conda uses. Our workflow starts with a base vanilla python (currently 3.7.3). From there, we manage packages manually with pip. There's no need for another python interpreter or conda. What I really need is a listing of those packages (preferable as a requirements file) so I can minimize the number of `pip install yet_another_package` commands I need to execute to get things working. – Michael Szczepaniak Dec 31 '19 at 20:48

1 Answers1

0

My suggestion is to normally use Anaconda and, once your env is fully set prepare a requirements.txt with the following command:

conda list -e > requirements.txt

This file can then be used with pip in a normal venv to install every requirement again:

pip install -r requirements.txt

If you really don't want to install Anaconda you can also use its minified version, miniconda.

Pitto
  • 8,229
  • 3
  • 42
  • 51
  • 1
    That's clever. A little time consuming, but seems well worth it. – Michael Szczepaniak Dec 31 '19 at 20:05
  • There are many scenarios where a solution like this will fail. For example, packages may be registered in Anaconda cloud that do no exist in PyPI. Anaconda is also able to pin C dependencies and use correct versions for building certain libraries from source (a notable example is trying to build old versions of Pandas via pip). – jII May 19 '20 at 06:03
  • Good point, @jII . I wrote my answer based on the question that states "...with a few packages installed that are commonly used." and it worked well for the op. – Pitto May 19 '20 at 13:55