[Python-Dev] OT: single directory development [was Re: Playing with a new theme for the docs]
PJ Eby
pje at telecommunity.com
Wed Mar 28 07:18:33 CEST 2012
On Tue, Mar 27, 2012 at 9:02 PM, Ethan Furman <ethan at 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~
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120328/e66048ab/attachment.html>
More information about the Python-Dev
mailing list