On Tue, Mar 27, 2012 at 9:02 PM, Ethan Furman <et...@stoneleaf.us> wrote:
> PJ Eby wrote: > >> Really? I've been doing "dump the app in a directory" since 1998 or so >> on various *nix platforms. And when distutils came along, I set up a >> user-specific cfg to install in the same directory. ISTR a 5-line >> pydistutils.cfg is sufficient to make everything go into to a particular >> directory, for packages using distutils for installation. >> > > Perhaps somebody could clue me in on the best way to handle this scenario: > > I develop in a single directory: > > c:\source\loom\ > loom.py > test_loom.py > > because test_loom could at some point be executed by somebody besides me, > while living in site-packages, I have test_loom.py create its needed files, > including dynamic test scripts, in a temp directory. While this works fine > for site-packages, it doesn't work at all while testing as the test script, > being somewhere else, won't be able to load my test copy of loom. > > I know I have at least two choices: > - go with a virtualenv and have my development code be in the > virtualenv site-packages > - insert the current path into sys.path before calling out to > the dynamic scripts, but only if the current path is not > site-packages > > Suggestions? > At first I didn't understand the question, because I was misled by your directory layout sketch -- AFAICT it's completely irrelevant to the real problem, which is simply making sure that the directory containing loom.__file__ is on sys.path. I'm somewhat hard-pressed to see, "embed the virtualenv tool in my test script" as superior to either "Copy the modules I want to the temp directory alongside the modules" or "setup sys.path when running the scripts" (e.g. by altering the PYTHONPATH in the child environment). (I'm not clear on why you want to skip the path alteration in the site-packages case - is there something else in site-packages you don't want having top import priority? And if not, why not?) All that being said, I can see why under certain circumstances, a virtualenv might be an optimal tool to reach for; it's just not the *first* thing I'd reach for if a sys.path[0] assignment or environment variable setting would suffice to get the needed module(s) on the path. > ~Ethan~ >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
