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
py_compile cannot create files in current directory #56827
Comments
When you specify cfile to be in the current directory, an error occurs (line 133). |
Please create a patch in unified format. |
The attached file just works. |
It might work right now, but in case the file changes before your change can be processed, we will lose the previous changes if we just copy in your new file. IOW, you're making our work much harder and your change is less likely to be applied. |
Makes no sense to me: since I don't have the trunk version, I can only diff -c against 3.2 release. Doing a diff against trunk is 1 sec of work for you. But I am just being a helpful user; so if a diff is what you want, here it is. No trouble for me, since I am on Linux. Not a very nice policy to any helpful Windows users, though: they won't have diff installed and they would waste an hour or so on this. |
It's a context patch, not a unified patch, and it is reversed :) . |
Well, we can work with this patch. Thanks. Yes, we can diff against 3.2, but for that you would have at least needed to specify
Otherwise, we cannot know what to diff against. Note that even Windows users usually use Python from Mercurial for developing, so that they can use "hg diff" to create a patch easily. |
Good to hear that the patch is helpful. Again, I am just trying to be a helpful user, making a (very very little) contribution to make Python better. I am not a Python dev at all: Python is already awesome enough for me, no desire to change it :-) I did indicate "Python 3.2" in the bug report, maybe something went wrong. |
It's rare to receive fixes from Windows users that don't have a dev environment set up (i.e. they just edited their stdlib code in place, or copied it and created a modified version). Thanks for persisting in the face of invalid assumptions on our part. |
Sjoerd, can you paste the code that produces the bug? It would help create a test. |
Hi Éric, There you go, adapted from http://effbot.org/librarybook/py-compile.htm : ############ import py_compile
# explicitly compile this module
py_compile.compile("py-compile-example-1.py","py-compile-example-1.pyc") ############ Also, I tested and this bug is present neither on 3.1 nor on 2.x cheers |
I can reproduce in 3.2 and 3.3. I’ll commit a test and patch when I get the time, or another dev can take this over. |
I think it might be easier to just always use the absolute path rather than looking at the directory length. Maybe something like the attached. I added unit tests as well. |
Thanks for the patch Meador, I hadn’t realized we had no tests for py_compile (it is however used in test_import and test_compileall). I think it would be nice to commit the tests first (except for the one that’s the object of this bug report) in order to have a baseline, and then see about fixing this bug. I’ll do that in a few days if nobody objects. I’m not sure there would be no negative side-effects to using os.path.abspath; we don’t know what people do with symlinks and relative paths out there, so I’d prefer adding a safe special case* rather than always calling abspath. What do you think?
if parent: # empty string means current directory, skip creating the dir
os.makedirs(parent) |
Meador, maybe you would like to commit the tests (except for the one that’s the object of this report) yourself? I don’t mind doing it, but as you have push rights now maybe you prefer to have your name directly associated with your work. |
Éric, sure, I will commit the tests sometime today. Then I will respond to the 'os.path.abspath' question as well. |
New changeset bcc7bf3963cc by Meador Inge in branch '2.7': New changeset 2be3a2e63683 by Meador Inge in branch '3.2': New changeset f8f58db0715e by Meador Inge in branch 'default': |
The tests break on the Windows buildbots: ====================================================================== Traceback (most recent call last):
File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_py_compile.py", line 33, in test_relative_path
py_compile.compile(os.path.relpath(self.source_path),
File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\ntpath.py", line 622, in relpath
raise ValueError(error)
ValueError: path is on mount 'c:', start on mount 'D:' |
On Sat, Nov 26, 2011 at 7:17 AM, Antoine Pitrou <report@bugs.python.org> wrote:
I am investigating now. |
New changeset b23453530d5f by Meador Inge in branch '2.7': New changeset 7097d52cacee by Meador Inge in branch '3.2': New changeset 5243752e19aa by Meador Inge in branch 'default': |
The tests are fixed now. A relative path was being computed, but on Windows the current working directory drive and the drive of the relative path we were computing was different (and so this test bug would *not* be seen if running on a Windows box with a single "C: drive" setup). /me sighs at the concept of Windows drives. Thanks for the heads up on the test break Antoine. |
Éric, I agree. I didn't know about the strange symlink + relative path Also, this is not an issue for Python 2.7. The 2.7 implementation [1] http://mail.python.org/pipermail/python-dev/2005-December/058452.html |
|
New changeset 661fb211f220 by Meador Inge in branch '3.2': New changeset e3647275f468 by Meador Inge in branch 'default': |
The regression test for this issue was already committed for 2.7 in bcc7bf3963cc as a part of creating the unit test baseline. I just committed the bug fix to 3.2 and default. Thanks for the fix Sjoerd. |
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: