On 04Feb2017 08:10, Neal Becker <ndbeck...@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 <c...@zip.com.au>
--
https://mail.python.org/mailman/listinfo/python-list
