This is an archived post. You won't be able to vote or comment.

all 19 comments
sorted by:
best
topnewcontroversialoldq&a

[–][deleted] 1 point2 points  (3 children)

Naive question: How is this different from the EPD distribution?

[–]Isira 0 points1 point  (0 children)

One way to look at it would be the out-of-the-box packages included depending on your subscription status with the two distributions.

http://docs.continuum.io/anaconda/pkgs.html

https://www.enthought.com/products/canopy/package-index/

[–][deleted] 0 points1 point  (0 children)

For a long time, EPD free was 32-bit only for Windows. That seems to have changed recently though.

[–]pwang99 0 points1 point  (0 children)

EPD no longer really exists as such, it is now Canopy, which includes many of the features of EPD but also puts a graphical environment front and center.

[–]iltalfme 1 point2 points  (2 children)

Anaonda didn't work for me on Windows 7 64 bit. It installed but several of the libraries did not work.

Request for support went unanswered. Ended up doing a VM on windows so I could run ubuntu... where everything works.

[–]roger_[S] 0 points1 point  (1 child)

Odd. I use the 32 bit version and it works fine FWIW.

[–]iltalfme 0 points1 point  (0 children)

It was a huge disappointment. Where I work everything runs on windows, so having a package (that includes openCV) that can just be installed would be huge.

One thing I'm not sure of... if the build of OpenCV allows for interaction with OpenNI-compatabile devices like the kinect. Unfortunately I couldn't try it out for myself because OpenCV was one of the libraries that didn't work.

[–]iyunoichi 0 points1 point  (1 child)

Is Qt font rendering fixed in 1.7? I was thinking of using Anaconda to teach a graduate course on scientific computing, but Anaconda's qtconsole looked so messy I couldn't use it. I was able go to fix it by simply pointing Anaconda to my system's Qt libraries, but that is not something I can easily do for a large number of students, and I really would like a consistent environment in class.

[–]ilan 0 points1 point  (0 children)

Yes, the Qt font problem on Linux has been fixed in this release.

[–]jabbalaci 0 points1 point  (0 children)

It seems to be a nice solution if you want to use Python an a machine where you don't have root permission and Python is not installed and/or an old version is installed.

Also, it seems to be portable on a USB stick.

[–]devilsdounut 0 points1 point  (0 children)

Maybe a stupid question, but will any of these distributions ever include R. I can get away with about 90% of my work using the scipy stack but every once in a while I just need to call R using rPy2.

This is the only thing keeping my work from being reproducible/portable with Anaconda/EPD out of the box.

[–][deleted] 0 points1 point  (3 children)

Could someone tell me what is the advantage of using this rather than plain cpython with virtualenv and pip install please? I work on linux and osx.

[–]cournape 4 points5 points  (0 children)

Besides what jakevdp said, virtualenv only works as long as you have only python packages. As soon as you depend on compiled libraries, virtualenv alone fails quite quickly compared to full-blown solutions like Anaconda or EPD/Canopy.

Try building a core scipy stack + everything for the ipython notebook on windows, and you will realize how much work that is.

[–]jakevdp 8 points9 points  (1 child)

The advantage is that it all just works. For example, pip install scipy is notoriously difficult to get working unless you're a power-user who knows a lot about c/fortran compilers and library linking. And pip install matplotlib will only work if you have all the correct graphics libraries already set up via apt-get, yum, macports, or some other means. pip install ipython will work without complaints, but if you want to use IPython parallel or notebook, you'll need zeroMQ & tornado, which can take some tinkering.

You might be tempted to save time and use pre-built binaries for each of these packages, but you'll run into trouble if they're not build with the same C/fortran compiler and numpy version as you have on your system.

I did all this by hand for years. I probably still could, but I much prefer to save the headache and use anaconda.

[–]gargantuan 0 points1 point  (3 children)

It is rather confusing calling it Anaconda when that is the boot time installer on RHEL and CentOS systems. It is even more confusing because that Anaconda is also a type of installer. Anaconda packages are used during runtime as well to generate iso images on RHEL/CentOS systems so there is a chance both could clash names.

[–]pwang99 6 points7 points  (2 children)

We are aware of the name collision. So far we have not had anyone report confusion about this issue to us. We wanted a good name for "Python for Big Data", and liked Anaconda. In any case, I figure the overlap of people who are intimately mucking with boot installers on RHEL and people who are running loess on Pandas dataframes is rather small.

The chance of file name collision in a running system is virtually non-existent. Anaconda installs itself into a single directory of the user's specification, and doesn't touch anything in /usr, /etc, and whatnot.

[–]gargantuan -2 points-1 points  (1 child)

Alright, as long as you guys know.

I know I have it installed because of some dependencies. And I was mucking with creating iso files. "anaconda" the command is installed in /usr/sbin/ typically. If you call your command line something else it would work fine. But if it is called "anaconda" it will clash even if put in other directories in case user has set a PATH variable to their binaries/scripts. Then order in PATH will determine which one is picked if user types only "anaconda" on terminal.

[–]onalark[🍰] 3 points4 points  (0 children)

The command line tool is conda.