New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sys.path[0] when executed thru a symbolic link #42713
Comments
Under certain conditions there is a difference between This difference appears when the script is called ~/TESTPATH/sub1/testpath.py In both cases, under Linux and Mac OS X, the result is: /home/owner/TESTPATH/sub1 If a different user executes: ~owner/TESTPATH/sub1/testpath.py he gets the same results under Linux: /home/owner/TESTPATH/sub1 but two different results under Mac OS: /Users/owner/TESTPATH/sub1 This seems like a minor problem but it breaks my I am not sure whether this is a Python problem or |
Logged In: YES I don't see this problem: both users see "sub1" as the working directory. Also My guess: there is some problem with the readlink() call that Python uses to I wouldn't be surprised if it is some sort of permission problem (maybe / |
Logged In: YES (1) I think it is a problem because under Mac OS X the user (2) The problem persists even if all permissions are open. (3) The implementation of "os.readlink" migh be the right OSError: [Errorno 13] Permission denied: even though all permissions are open. Under Linux I get the expected answer: "../sub1/testpath.py". Obviously there is a problem under Mac OS X, and this matter |
Just came across this when running hadoop jobs I just reproed this with python 2.7.3 on a new ubuntu system: repro:
You would have expected "/home/kristjan/pydir" since this is the apparent directory of the file. When "pydir" contains many .py files, each residing in their own unique real target directories, then they cannot import each other. |
The haddoop thingie in question is called cloudera CDH4 |
That's questionable. Changing this to not resolve the symlink would break some use cases. An alternative would be to add both the original and target directory if they differ, hoping that there's no conflict in the modules. |
There is no "binary" here contributing to the problem. The particular case is a the hadoop runtime engine which creates a "virtual" folder of your working directory. We have set up a directory of .py files: foo/ The hadoop job is then to run a.py. It is run simply as python a.py. In this case, by cd-ing into the dir and running the file. hadoop knows nothing of python and merely executes the given file. Now, what this hadoop implementation does, however, is to create a virtual symlink image of your project directory, and duplicate this in various places, e.g.: tmp1/ tmp2/ Notice how each file, previously together in a folder, now pyhysically resides in a unique place. This means that a.py can no longer import b.py. I am unaware of a workaround for this issue which does not involve modifying the individual .py files themselves to set up a path. Fixing this would mean that rather than to
I am not sure about what use cases could be broken by the above change, do you have examples? |
For example: /tmp/
With foo.py containing "import libfoo". Now, calling /tmp/foo.py works because sys.path[0] == If we change sys.path[0] to not dereference the symlink (that's how I That's AFAICT exacyly the problem reported by the OP on OS-X. |
I've no clue what happened to the issue title (I just replied to the email, and the title changed)... |
Thanks for your example.
IMHO, the example you quote is "unexpected". The purpose of symbolic links is to create a "virtual" image of a structure. contains only a foo.py in its apparent location (scripts). I would not expect the file to be able to import stuff from /otherplace unless that stuff were also present in /scripts In other words: symlinking individual files normally works like you are "pulling that file in", not "hopping into that file's real location". This behaviour is unexpected because I know of no other language tools that behave in this way: /code/ an "#include "mylib.h" in myfile.c would look for the file in /code and find it. Since this is not the original problem described, I'll open up a separate defect report. |
Closign this again. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: