/tmp/a.py --- print('hello') --- /tmp/b.py --- #!/usr/bin/python import a --- # cd / # /tmp/b.py hello # mv /tmp/b.py /usr/lib/python-exec/python2.7/ # ln -s /usr/lib/python-exec/python-exec2 /tmp/b.py # /tmp/b.py Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/b.py", line 2, in <module> import a ImportError: No module named a
Wrapper is intended for scripts, not modules. If you have a real bug with a real ebuild, please report that instead.
I have real issue with package that was broken. It is not module. In python, and I am sure you know... if I put a script in a directory and another script in that directory the first script can import the second, as search path is the script directory then whatever in python path. This worked so far using the old wrapper and now is broken.
Can you please point us at the package(s) which were broken? python-exec:0 broke anything that relied on basename(argv[0]); it may not be possible to support both scenarios with the same code.
(In reply to Mike Gilbert from comment #3) > Can you please point us at the package(s) which were broken? > > python-exec:0 broke anything that relied on basename(argv[0]); it may not be > possible to support both scenarios with the same code. It is out of tree package for now. Quite simple package that contain some script and include shared module. Yes, it is not installed at /usr/lib/python as it is not for reuse by other modules. What is the problem with argv[0]? The following script modifies the sys.argv[0] to whatever required, so wrapper can put there whatever expected. What am I missing? --- #!/usr/bin/python import sys print(sys.argv[0]) sys.argv[0]='aaa' print(sys.argv[0]) exec('print(sys.argv[0])') --- The solution to put original script at the same directory of the wrapper solved did not assume unique names of scripts nor damaged the local module include. I may miss something regarding the argv[0], maybe it is something in native modules? but then the wrapper which is argv[0] contains the original script name (wrapper).
Also, you can consider adding the wrapper source directory (dirname(argv[0])) to the python path to allow scripts to find their local modules.
Well, thinking more about it, you are clearly doing something terribly wrong. The concept of python-r1 requires to keep a separate copy of all Python code for each implementation. This involves keeping modules in implementation-specific sitedirs, and wrapping scripts. If you're trying to import scripts relative to bindir, you are trying to reuse the same module with multiple Python implementations. That is not supported, not going to work and if it did, it would cause random issues (like .pyc file collisions). It seems that your package is not capable of supporting multiple Python implementations. And then, you are looking for python-single-r1 that does not use python-exec at all.
(In reply to Alon Bar-Lev from comment #4) The main python-exec wrapper is written in C and just calls exec on the scripts under /usr/lib/python-exec. There isn't any opportunity to manipulate sys.argv. We could rewrite the whole thing in python, but that may present other problems and may incur a performance penalty. If the issues were more widespread, that might still be worth considering.
