python setup.py develop [1] doesn't install anything. It makes a link to a directory of source code, just like you are doing w/ the pythonpath, and you only have to run it once. either method is accomplishing the same thing. I just find workingenv very easy to use and wanted to share since there isn't really any documentation on it.
[1] http://peak.telecommunity.com/DevCenter/setuptools#develop-deploy-the-project-source-in-development-mode On 2/9/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > I have a directory on my laptop which looks like this: > > ./sa026 > ./sa027 > ./sa028 > ./sa030 > ./sa031 > ... > > I set PYTHONPATH to "./lib". I change into each directory and run a > script that id like to compare between versions. No "setup.py develop" is > required...i dont want to install anything anywhere. I just want to use > *this source code right here*, even though an egg version of that software > happens to be installed somewhere. I dont see why thats so unreasonable. > > basically right now, once you install something via setup.py, you can > never ever again use any module with that same name without going through > setuptools hoops for it (or shove a "sys.path.insert()" in your program, > or hack your python like i did). > > > Kumar McMillan wrote: > > > >> > 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 -~----------~----~----~----~------~----~------~--~---
