undefined | Better HN

0 pointsWD-425y ago0 comments

> 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.

0 comments

darkarmani5y ago

> 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.

j / k navigate · click thread line to collapse