[WD-42]

It's way more than that. Firstly, most Anaconda installations come shipped with libraries like Matplot, numpy, etc. So a lot of people that use conda write software that assumes those libraries are always available e.g leaving them out of requirements.txt or setup.py.

Then there's the issue of Anaconda using it's own package repos, so even if you do manage to figure out what packages an Anaconda developed piece of software needs, you're getting a subtlety or maybe not so subtlety different version of it using standard pip, which creates the worst kind of hard to trace bugs.

Lastly, certain installations of Anaconda overwrite the system python version with it's own (so you can just use numpy or whatever anywhere) causing a huge headache with other system software and making using the standard distribution tools even harder.

I get that it's convenient for scientists that just want to write scripts and have them work, but if you're creating any kind of collaborative software, especially if you'll be working with SW engineers down the line, avoid Conda at all costs.

[darkarmani]

> So a lot of people that use conda write software that assumes those libraries are always available e.g leaving them out of requirements.txt or setup.py.

How is that any different than using python.org python? You'd still be unaware of what versions to use.

> you're getting a subtlety or maybe not so subtlety different version of it using standard pip, which creates the worst kind of hard to trace bugs.

That's way more of a problem with pip. You have no idea what versions a pip package is pulling in until install and then what binary actually gets installed depends on your compilers.

> certain installations of Anaconda overwrite the system python version with it's own (so you can just use numpy or whatever anywhere) causing a huge headache with other system software and making using the standard distribution tools even harder.

That's impossible unless one is actually copying binaries manually overtop of system binaries. You'd have to be root or use sudo to overwrite the system python manually. The whole point of isolation is to keep system python isolated and stable for system stability. That can happen if someone installs python from python.org and copies it into place.

> but if you're creating any kind of collaborative software, especially if you'll be working with SW engineers down the line, avoid Conda at all costs.

If you are working with SW engineers, you better know what versions you are pulling in, because you are going to be in serious pain using pip and trying to understand the provenance of your packages. Conda is way more powerful here for serious engineers to specify exact versions and reproducible and exact builds.

[WD-42]

> How is that any different than using python.org python? You'd still be unaware of what versions to use.

Because python.org doesn't ship with numpy, matplotlib, or any of those other packages. Anaconda does, which makes it possible to import those libraries in projects without explicitly listing them as dependencies.

> That's way more of a problem with pip. You have no idea what versions a pip package is pulling in until install and then what binary actually gets installed depends on your compilers.

What? The problem here is that conda has it's own repos, which contains different packages than are contained in PyPi. What exactly do you mean by "no idea what versions a pip package is pulling". You realize you can set versions, right? numpy==1.13.2. The problem is numpy 1.13 on Anaconda can be different than numpy 1.13 on PyPi.

> That's impossible unless one is actually copying binaries manually overtop of system binaries. You'd have to be root or use sudo to overwrite the system python manually. The whole point of isolation is to keep system python isolated and stable for system stability. That can happen if someone installs python from python.org and copies it into place.

This is just wrong. Anaconda overwrites the system python by messing with the user's $PATH regardless if you are in a conda environment or not (probably easy to disable this "feature" but I've seen a lot of people with this setup). This causes major headaches.

> If you are working with SW engineers, you better know what versions you are pulling in, because you are going to be in serious pain using pip and trying to understand the provenance of your packages. Conda is way more powerful here for serious engineers to specify exact versions and reproducible and exact builds.

I'm not sure why you think you can't specify exact versions with pip. Projects like pipfile take it even further. The issue with conda is it's different package repos, not the ability to lock package versions.

[darkarmani]

> Anaconda does, which makes it possible to import those libraries in projects without explicitly listing them as dependencies.

I think your main problems are very naive users of conda. If you bring years of experience using pip, but use conda thoughtlessly, I can see your point.

If you don't want packages included, just use miniconda and install the ones you like. You could just create a new empty environment: `conda create -n py36 python=3.6`

Either way, it's completely reproducible.

When not using wheels, pip can be pulling in various versions of dependencies. Conda makes it easy to see all of them before they are dumped into your environment.

> Anaconda overwrites the system python by messing with the user's $PATH regardless

I understand what you are saying now. It's covering up system python in the PATH, but it isn't overwritten. Using `type python` (or which python will be correct 99% of the time).

> The issue with conda is it's different package repos, not the ability to lock package versions.

I thought this was your major argument. "Collaboration is difficult" when in fact it is much, much easier. You are getting the same binary everytime without slight differences in how it ends up compiled on the user's system.