Anaconda 5.0 Released | Hacker News Reader

Anaconda 5.0 Released

anaconda.com

137 pointskawera64 comments

> Spaces are no longer allowed in the installation path on Windows.

Seems like a weird regression 16 years after Windows XP shipped with "My Documents".

I used Anaconda for a while, but I've since moved back to CPython. Most packages install fine on Windows using pip now, and the ones that don't is just a download away from http://www.lfd.uci.edu/~gohlke/pythonlibs/. Using the standard Python distribution is also nicer because of the python launcher, and it makes .py files executable like .exe and .bat.

Some packages you install might break if you have spaces in their path. Better to fail loud, fail early. I don’t think it’s «anaconda’s fault».

Spaces were only temporarily disabled; added back already in 5.0.1. It’s already been released.

Lots of software breaks with spaces though, and isn’t practical to patch at the distribution level. If you’re unfortunate enough to be using spaces, file issues with the upstream when things break and let them know.

> Seems like a weird regression 16 years after Windows XP shipped with "My Documents".

Interesting though, that 6 years ago they reverted back to simply "Documents".

In modern windows, essential user paths no longer need have spaces in them. The persistence of "Program Files" and the hilariously tricky "Program Files (x86)" are notable however.

What is wrong with spaces in file names? When my wife was doing research for her thesis she had all the papers she was citing named with the full title of the paper. Linux handled it fine, and it seemed utterly modern and natural to me.

For something like a programming language interpreter, it's just annoying.

C:\Program Files\Python 3.0\ vs C:\bin\python3

(when I was using windows, I installed python in c:\bin because I knew I would be typing it quite a bit)

I don't know much about windows but does it not have a $PATH like in POSIX systems? I seem to remember that typing "run cmd.exe" worked without having to give the full path of "cmd.exe".

Yes it's very similar. `;` separated rather than `:` (Because of the drive specifier e.g. `C:\`) and classically embedded variables surrounded with % e.g. `%JAVA_HOME%`, although these days powershell just uses $ variables just like everybody else.

Sure, and you just run "python" often enough, but you type the path otherwise enough too.

It is very easy to write a bash script that completely mishandles variables containing filenames with spaces, for example:

cp ${FILENAME} /tmp

Here you should have done:

cp "${FILENAME}" /tmp

Also, GNU make, still one of the cornerstones of building C and C++ libraries (since CMake and Autotools most commonly use that backend) cannot handle spaces in paths at all well.

That’s a problem with those tools that, frankly, should have been addressed long ago. There are ways for script creators to deal with spacing in names, but spaces have been supported for decades now, on every OS, so it’s silly that the tools we use every day act like they don’t exist.

While I agree with what you have said, as creators of a software distribution bundling software and a build system to build more software it would be remiss of us not to warn people when they try to install said software into a path containing spaces.

Though as @kalefranz said already, we do allow it on Windows, we just warn loudly.

Also as far as I remember Windows doesn't distinguish between capital and lower case letter in file paths

Yes it does. By default it is case-preserving, case-insensitive but there is a registry key to enable case-sensitivity.

https://superuser.com/q/266110

Thanks.

That's a problem with the shell, not the tools.

The shell is deciding whether something is one arg or more, and passing the arg list to the tools.

It is also an unavoidable problem with GNU make and an easy to make mistake when writing CMake files. These tools should have required quoting up-front so filenames are never seen without them but it's a bit late in the day now to suggest fixing this.

I'd include the shell as one of the tools we use on a regular basis. If I use a command like scp with wildcards in the input path, and the files that are returned contain colons, for example[0], the fact that the shell doesn't quote every file with a space or colon in its name before passing it off to scp is a deficiency in the shell, which gets reflected when scp refuses to copy it.

[0] https://stackoverflow.com/questions/14718720/how-can-i-scp-a...

"if ifs and buts were candy and nuts, we'd all have a merry Christmas"

Escaping spaces in every command is not super fun/user friendly.

I do like Anaconda and it's a really great way to easily get Python on the computers of the people I teach. However, I do have some problems with how they mess about with the Python ecosystem. If you read a tutorial on Python modules, it will tell you to `pip install`, create a venv etc.

Anaconda have removed the ensurepip module (part of the standard library since 3.4) which is used during the venv creation to install pip. PEP 453 explicitly recommends that "Even if pip is made available globally by other means, do not remove the ensurepip module in Python 3.4 or later." to ensure that the `venv` module works as expected.

The lack of an `ensurepip` module means that trying to create a venv with `python3 -m venv my_test_venv` gives an error of:

  Error: Command '['/home/milliams/my_test_venv/bin/python3', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

People say that this is ok since `conda` is better but I don't want to have to teach my students the standard tools for Python module development only to have to say "except if you're using Anaconda...". Especially since the really shouldn't have to know what distribution they are using. It should be an implementation detail.

conda is the standard tool. tell your students to use it, not venv. problem solved.

> conda is the standard tool.

Since when? I was under the impression it's a data science focused alternative to the standard tools(pip, venv module, eventually pipenv).

It's standard within Anaconda. I think the subtext is that if you have the students install Anaconda, they should use Anaconda tools. If you want standard python, then install standard python.

If you're doing/teaching scientific computing with Python, it's widely used, if not "the" standard. Anaconda will almost certainly be available in any current scientific computing environment.

Any cloud computing environment focused on data science or machine learning will have Anaconda installed by default (and for good reason).

The sheer amount of complex dependencies and possible errors between build-time configuration and run-time libraries is vast. Anaconda helps people steer clear of a large amount of them, and that is why it's so popular.

This situation is exacerbated by the fact that, for Windows, Anaconda is the only way to get packages like numpy etc. working without downloading prebuilt wheels. If pip on Windows worked reliably Anaconda would have no need to exist.

To be honest, I never needed Anaconda to use NumPy/SciPy/matplotlib/pandas on Windows. I get that Anaconda makes it easier for people new to Python. But for seasoned Python folks, there's really no headache.

NumPy (and I think SciPy) used to be standard Windows installs (as in download an exe and install it). Pandas was too, but now you can use pip. The only catch was that you should install 32 bit python instead of 64 (not sure if that's still the case).

Not true. Anaconda/miniconda also provide a convenient way for package control which include binary packages and source code packages

For me, condo is good solution to install necessary dependences with little pain.

glad java doesn't have this problem 99.9%. even if you teach very old java. it would still work today.

We have put `ensurepip` back in place and uploaded new Python packages for all platforms. `conda update python` should see you right. Thank you for bringing this up.

Thanks Ray, it's very much appreciated!

Very excited for this. My go-to is still regular old pip and virtualenv, but I love anaconda for /not/ having to compile MKL / BLAS on my own in every new environment I use.

Also check out the JupyterLab alpha which comes with this, which is very neat:

https://channel9.msdn.com/Events/PyData/Seattle2017/BRK11 (demo starts around 15:00)

This adds support for new compilers.

This makes Dask (pure Python paralleization) run 20% faster https://twitter.com/mrocklin/status/923581208482721794 according to Matthew Rocklin, the main developer

Easy availability of gcc 7.2 on CentOS 6 is kind of a big deal.

As is (actually working, usable) clang 4.0.1 on macOS 10.9

Not that big. A few minutes of following the instructions and you can build it in a docker container, post it as a tarball that anyone can use without needing the rest of miniconda to install.

I don't think thats true. Our compilers are complete pseudo-cross compilers (i.e. with binutils, glibc, kernel headers and their own sysroot) that can be both hosted on and always target CentOS6. This means software built with them will run on CentOS6 and will not, by default, pick up your CentOS6-incompatible headers and libraries in /usr/include and /usr/lib respectively.

None of that requires conda to be able to do. Can also build in a chroot, without needing an unconventionally configured compiler, if you want to make your binaries redistributable - which is a requirement some users will have but not all. "Easy availability of gcc 7.2 on CentOS 6" doesn't require being able to build for centos 6 from something newer, docker or chroot tools are fine for that.

I love Anaconda. To me it is the most obvious way to do Python. If you don't know what is going on with your env exactly, just go to your Anaconda folder and investigate. I have done some pretty funky stuff just messing around and have never had problem. Great work!

Is anyone using conda to manage environments with versions of other languages/runtimes? For a while, I was using it to maintain different nodejs and ruby runtimes and package-sets, but stopped around node 6.6.0, mostly because I never got efficient enough at creating packages to create conda packages for different ruby or packages other than the interpreters themselves.

If anyone feels like it, you can run `conda create name=trycondanode --channel amfarrell nodejs=6.6.0`

Have tried for C, C++, Fortran, Julia, and a bit of R. Too many pythonisms (and requiring a fairly heavyweight miniconda setup to run) for it to work naturally when you actively don't want to be using any python. I think the lackluster adoption by any other communities is evidence of "language independence" not working out as smoothly as claimed.

If I'm fluent with virtualenv and already use it for all of my Mac OS X Python development, is there a reason I should still consider trying Anaconda?

It ships with intel MKL optimizations for e.g numpy/sciy. That’s a lot of hassle to get working in a virtualenv, not to mention maintaining several!

MKL is also multicore parallelized out of the box.

Isn't that working on the Mac ootb as well? If I install numpy it links it against https://developer.apple.com/documentation/accelerate which is very close to MKL/OpenBLAS performance.

There are also tons of other libs that apple don’t have equivalents for. E.g GDAL, libgfortran, and lots of others.

Not sure if Accelerate is multicore ootb?

Yeah, it allows working with multiple Python versions fine, like not just 2 vs 3 like on modern Linuxes, but also having one virtualnenv use 2.4, another 2.7, another 3.6 etc.

Couple this with good support for Windows too, and it's basically the only usable cross platform Python version manager... kind of sad all this functionality is not baked into core CPython's package, it would make language adoption 10x easier since "multiple python madness" is what trips newbies, especially if they use Windows or a Linux they don't administer themselves...

Also nicely optimized precompiled stuff, again, for the benefit of new Windows users, for which anything that needs compiling anything has a 50% change of breaking.

If you use data science libraries like numpy, pandas etc then these rely on OS level packages like libgfortran and liblapack. Anaconda is a way to guarantee you are running a known stack from dev machine through to production. This is the key benefit IMO (as well as getting improving deploy times)

All these packages provide wheels on OS X, there is no need to install gfortran these days.

A good point about a known stack.

Many people who do data science on OS X have to deploy or scale their things on Linux servers. Or serve Python scripts to collaborators on Windows.

Even if you are a working on an island and you fully control your own dev and production environments, there are myriad subtle divergences between the build toolchain on Linux and BSD/Darwin that can trip you up.

I don't know if you use some of Enthought's tools like MayaVi and such, but those used to be a pain to install under MacOs. I haven't tried lately though without Anaconda (it's just incredibly convenient).

https://docs.anaconda.com/anaconda/release-notes

Last time I checked it didn't work with virtualenv. Does it now?

Yes. conda install -c conda-forge virtualenv

That version is patched to fix previous incompatibilities.

Anaconda has his own mechanism to create a virtual environment. You use the conda command to create a new virtual environment: https://conda.io/docs/user-guide/tasks/manage-environments.h...

Right. If you’re stuck on python virtualenv, you can use it if you want. Conda environments are more general. Light-weight environments for any language or runtime or aggregation of packages, not just python.

It's own environments mechanisms is even better: each environment can have it's own separate python version!

The "miniconda" installer variant is something I even use in production when on the same server I need to run microservices one written fro Python 2.4, another for Pythn 2.7+, another for Python 3.3, another for Python 3.6+ etc.

Really, anyone doing Python should embrace conda envs - they are awesome and allow skipping the entire "Python 2 or 3" useless discussion and replacing it with "just use whatever python you want", just specify it clearly... The whole "2 vs 3" incident would never even have existed if people people would've had something like Node's NVM or Ruby's RVM, and "conda envs" it's basically this, only that it combines support for its own special package formats with this.

You can do that with virtualenvs, too. `mkvirtualenv -p python3.6` for example. When you activate that virtualenv, it uses that interpreter version.

Can you also install separate python versions this way? like have it automagically download a precompiled python3.6 for you even if there may not be a distro package for it.

I don't really like having to depend on the system's python binaries and their packages, but I don't want to compile my own either. But I do know most people would violently disagree with me on this :)

(I just happen to be both incredibly lazy and a control freak at the same time :P...)

yes, you just need to find a channel that has that version published, trust the person maintaining that channel, and do something like `conda install --channel amfarrell nodejs=6.6.0`

I was asking the question about non-anaconda python, aka "plain python with virtualenv" that I think GP was referring to...

You can also install your own separate nodejs version in each environment. Or your own separate ruby version.

> The whole "2 vs 3" incident would never even have existed if people people would've had something like Node's NVM or Ruby's RVM, and "conda envs" it's basically this, only that it combines support for its own special package formats with this.

What is this "2 vs 3" incident and how would a better version manager solved the problem of Py2 packages not migrating to 3?

Ooh. I really thought a new anaconda movie is coming.!!!

Reply on news.ycombinator.com