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