Home Original page

best way to ensure './' is at beginning of sys.path?

Cameron Simpson cs at zip.com.au
Sat Feb 4 18:01:17 EST 2017 
On 04Feb2017 08:10, Neal Becker <ndbecker2 at gmail.com> wrote:
>Neal Becker wrote:
>> I want to make sure any modules I build in the current directory overide
>> any
>> others.  To do this, I'd like sys.path to always have './' at the
>> beginning.
>> What's the best way to ensure this is always true whenever I run python3?
[...]
>Sorry if I was unclear, let me try to describe the problem more precisely.
>
>I have a library of modules I have written using boost::python.  They are
>all in a directory under my home directory called 'sigproc'.
>
>In ~/.local/lib/python3.5/site-packages, I have
>
>--- sigproc.pth
>/home/nbecker
>/home/nbecker/sigproc
>---
>
>The reason I have 2 here is so I could use either
>
>import modA
>or
>import sigproc.modA
>although I almost always just use
>import modA

Is this desirable? For myself, I would go to the effort of always using one 
convention. In particular, often a name like "modA" will be ambiguous/generic 
because it lives _inside_ a descriptive namespace (sigproc). By generally using 
"import modA" you leave yourself open to conflict with some other "modA" if 
such a thing is ever loaded in an environment in which your code must run.

I'd be wanting to either go:
  import sigproc/modA
or
  from sigproc import modA
myself.

>Now I have started experimenting with porting to pybind11 to replace
>boost::python.  I am working in a directory called pybind11-test.
>I built modules there, with the same names as ones in sigproc.
>What I observed, I believe, is that when I try in that directory,
>import modA
>it imported the old one in sigproc, not the new one in "./".

Because python is using your general purpose "stable" sys.path.

>This behavior I found surprising.  I examined sys.path, and found it did not
>contain "./".
>Then I prepended "./" to sys.path and found
>import modA
>appeared to correctly import the module in the current directory.

Might I commend to you my "dev" script suggestion. To my eyes it seems that you 
want "modA" from your development directory. For myself, when I do this, I just 
invoke command like this:

  dev python3 blah blah ...

which runs things with the local dev tree at the front of sys.path.

>I think I want this behavior always, and was asking how to ensure it.

You may want it, but I recommend against it. Having "." in your sys.path, 
_especially_ at the front, leaves your programs open to subversion/misbehaviour 
simply if you stand in an unfortunate directory. It is like a little time bomb 
waiting to go off in your face.

If you really want this, modify your $HOME/.profile (or equivalent, depending 
on your shell) to prepend "." to your $PYTHONPATH, eg:

  PYTHONPATH=.${PYTHONPATH:+":$PYTHONPATH"}
  export PYTHONPATH

But really, consider making yourself a convenient script to make _temporarily_ 
using the current directory as a source for packages/modules easy to do. For 
_testing_ purposes. When your code is stable/releasable, release it into your 
normal environment, where everything will benefit.

Mine is here:

  https://bitbucket.org/cameron_simpson/css/src/tip/bin/env-dev

for comparison.

I use a personal shell function to invoke it as "dev", but that is mere finger 
convenience.

Cheers,
Cameron Simpson <cs at zip.com.au>
More information about the Python-list mailing list