> > put a file "aaaa-pythonpath.pth" into your site_packages folder:
> >
> > import os, sys; sys.__egginsert=len(os.environ.get('PYTHONPATH',
> > '').split(os.pathsep));
> duly noted for future usage _when_ i meet an egg.workingenv, as Simon King mentioned, is the way to go. At my company we share a dev server which has lots of stuff complied for us but for true isolated development, each developer needs his own python sandbox to make egg links to all modules in progress. $ sudo easy_install workingenv.py $ python -m workingenv --site-packages ~/temp-py $ source ~/temp-py/bin/activate and now you can run `python setup.py develop` without sudo on any package and it will only be available in that env, with a fallback to site-packages for modules you haven't installed. And of course you can have as many of these as you want. Some things I've run into... when setuptools gets upgraded (why a workingenv feature isn't built into setuptools, who knows) sometimes you need to remove the setuptools egg and rebuild your workingenv the same way you built it $ python -m workingenv --site-packages ~/temp-py this will not disturb any eggs or egg-links in your env. The only alternative (quoted above) that I know is to hack your python install (which I also did before workingenv). I still find workingenv easier, tho not ideal. I should also note that this was a perfect way to set up multiple buildbot builders on our server. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
