On 7/18/2013 9:24 PM, Nimret Sandhu wrote:
looking past the hubris in your email,
Wow.
you're talking about dependency management [DM] (http://en.wikipedia.org/wiki/Dependency_hell) which exists in libraries, OSes and pretty much anywhere there is coupling between reusable code. It can be solved statically by linking against specific versions which work together but is a little more challenging to solve dynamically. There are tools in python to manage this though - http://www.pip-installer.org/ for compile time and http://www.virtualenv.org/ for runtime. java has maven, gradle, etc for compile time DM and tech like osgi for runtime DM. apt-get on *nix, ports on bsd are tools on OSes for addressing the same issues. They all work rather painlessly without 'ridiculous amounts of work'.
This is well beyond dependency hell. It's compiler and linker options and many other things. If you think pip solves these problems, then you haven't tried to use pip to install the dependencies for ipython notebook on Windows. And certainly haven't tried is across the wide variety of Windows and Pythons brought into a classroom. These problems don't even start to get addressed until the setup.py, and then only for the Python bits.
If it wasn't a ridiculous amount of work, there wouldn't be a need for prepackaged "sumo" distributions like Canopy or Anaconda. Comparing this to apt-get and ports misses the point. With apt-get, you are sometimes able to install some pieces of the Python scientific stack for the particular system python that apt-get repo for that particular OS and OS version is also managing. But that's rarely what anyone needs. It only works because someone has already done the ridiculous amounts of work packaging binaries for a particular narrow use case. pip gets from a generalized repo of python source with setups that often run compilers and linkers in the case of scientific packages.
Virtualenv simply gives you a sandbox to play in to isolate at least the Python parts of the ridiculous amount of work. The ironic thing about pointing at virtualenv.org is that the first three points on the front page under the installation section are version dependency warning.
see http://goo.gl/IzI1i
The ironic thing about that link (a Google search for python pip virtualenv scientific computing) is that the top two links are about the problems pip and virtualenv have trying to install the Python scientific stack.
The first sentence in the first link was, "For whatever reason, it can be a big pain to get python set up correctly on Mac OS X." Later on it goes on to say, "Next is the tedious process of downloading and installing packages. Unfortunately some of them do not play well with pip and need to be built from the latest source code explicitly. Others simply take a long time to build and you may want to avoid repeating the build when creating a new python virtual environment. Still others don’t build well and need to be installed using pip. Good times."
The second link goes on about how, "Now, we would like to install matplotlib, which is a 2-D plotting library for Python. Now Matplotlib is not very friendly with pip/easy_install on many systems. So, we will install from source."
-- Sincerely, Chris Calloway http://nccoos.org/Members/cbc office: 3313 Venable Hall phone: (919) 599-3530 mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599
