Baby steps with easy_install

·—— ···· ·· — ····· ···—— ——···
Per my last post, I'm sipping some setuptools kool-aid. Here's a report of progress so far.
  1. I compiled and installed a Python 2.5 system under ~/python/2.5-easy_install expressly for this experiment. The interpreter is accessible as ~/bin/ezpy.
  2. I cleared out the remaining vestige of a previous abortive attempt to grok setuptools (easy_install in /usr/local/bin).
  3. I downloaded ez_setup.py and ran it using ezpy. It installed the script and libraries under ~/python/2.5-easy_install , as I'd hoped it would.
  4. I ran easy_install nose, then ezpy -c "import nose". Looks like it worked.
  5. I ran easy_install urwid, then ezpy -c "import urwid". Looks like that worked too.
  6. For kicks, I ran nosetests -w site-packages/testosterone/tests in my testosterone development directory. It didn't find any tests, but easy_install had installed nosetests in ~/python/2.5-easy_install , as I'd hoped.
So easy_install is working as advertised. It was indeed easier to install nose and urwid using easy_install than otherwise, although neither had any dependencies. In my experience, packaging systems break because of conflicting dependencies (actual packaging bugs being rarer). And my gut is that there's some kind of stability threshold at maybe a dozen packages or so. It makes sense, then, to use easy_install with some kind of quarantine system.

On a related note, I generally like to bundle all dependencies with whatever system I'm deploying or distributing, rather than relying on remote URLs, because remote URLs aren't under my control: they can change, sites can go down, etc. To me, the control and simplicity of having all dependencies together in one place is worth the redundancy. Afaict this pattern could still fit with easy_install if one were to build "monolithic" eggs.
·—— ···· ·· — ····· ···—— ——···
Feed back to Chad Whitacre.