You are totally spot on in your description of how hard it can be to install stuff. Years ago the first time I tried to install some Python 2.x version from source on OS X I ran into the problem that the filesystem is case insensitive. I've tried to install PIL at least 3 times and never got the dependecies right.
On Fri, Jul 19, 2013 at 11:36 AM, Chris Calloway <[email protected]> wrote: > 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<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 > -- Some radio waves were modulated in the creation of this email.
