call to nt.assert_true(path._writable_dir(home)) returns false in test_path.py #1998
Comments
|
mmh, could you explain a bit further what you were doing and under what conditions this failed? Without some more information, there's not enough here for us to know what to fix. |
|
Sorry. I misread the traceback. You are correct. |
|
Unless we get actionable info for this within a few days, we'll have to close it; I don't know what we can do here. |
|
well, I simply run the test suite of the current ipython; Sorry for not making it clear to you. I've been badgered a number of times to not enter gentoo specific code or such, but this is quite simple. The second is a doctest error from from IPython test group: IPython.parallel. I hope this makes it clear and workable. Thanks |
|
I'm not familiar with gentoo, but it looks like you've got 0.12. Can you run the tests with a development version of IPython? We're coming up to a 0.13 release, so if there are bugs in the previous release, they may have already been fixed. |
|
well being gentoo doesn't alter the running of the test really. It's run from an ebuild and once run should be the same as running it manually from the source dirs. Anyway, yes it is 0.12 and I just noticed I ran 0.12.0, so I ran 0.12.1 and got the same for the get_home_dir() error. The second error is entirely different, So it supposedly got thru the doctest test in this run. The 1st error is persistent and sure it may be a CPython fault. |
|
On 22 June 2012 12:22, idella
Yep, or grab the beta release from a few days ago:
I suspect that it differs somehow. We test on Linux a lot, both |
|
ok with 0.12.1 I now have just the one fail still with the get_home_dir() error with python2.6 2.7 persistently, The traceback cites test_path.py line 163, that's how the title relates to the pasted output, not making that up. @with_environment
def test_get_home_dir_4():
"""get_home_dir() still works if $HOME is not set"""
if 'HOME' in env: del env['HOME']
# this should still succeed, but we don't know what the answer should be
home = path.get_home_dir(True)
nt.assert_true(path._writable_dir(home)) line 163.It seems a pretty trivial test so we're not playing for sheep stations. |
|
I was wrong earlier... was thinking The assertion is failing because What is the output of |
|
archtester dev-python # ls -ld /var/tmp/portage |
|
Are you certain the test suite is run as root? It seems like a reasonable thing to run third-party tests as a restricted user, in which case this dir would obviously not be writable. As root, what do you get for: import os
path = '/var/tmp/portage'
print "writable:", os.access(path, os.W_OK)
print "dir:", os.path.isdir(path)Because that's the sum-total of the In any case, we might just skip this fairly unlikely test case, as it only runs afoul of contrived unrealistic environments like most testing sandboxes. |
|
Are you certain the test suite is run as root? |
|
Sounds like the best thing to do is to just get rid of that specific test. It seems to me that we can't really guarantee that '~' will be writable if $HOME is not set (in testing environments)... It is certainly an odd corner case... |
|
Are we already running each test group with a tempfile-generated directory set as IPYTHONDIR? I don't recall if that's been merged or not, but that would solve this problem (and in general introduce a healthy decoupling between test groups and the enclosing environment). |
|
For completeness: The case this tests is that in any real, sensible (*ix) environment, the HOME variable is not necessary because the pwd package can be relied upon to get the home dir (as evidenced by the fact that this test has been passing for non-pathological environments for a long time). This comes up in various bundled app situations, where HOME need not be defined. This is failing because It is a bit silly to remove a perfectly functional and correct test, but at the same time, it's not really testing IPython - it's testing os.path.expanduser and the system passwd database, which do not give sensible values in this sandbox.
We are not, but I also don't believe that would change anything here. I think it's the sandbox itself that has pathological values, and once inside that sandbox the cwd for subprocesses should be irrelevant. |
|
Thanks for the careful analysis, @minrk. I suggest we close this and let the gentoo folks either figure out their build machinery or report it upstream to Python if they deem it an issue with pwd/os.path (and they can argue their point with the python folks, not us). Does that sound reasonable? |
|
I guess I should clarify my clarification a little bit :). While the test is fine and there is no IPython bug here, the fact that it mostly tests code totally outside IPython, I come down slightly in favor of removing the test, or at least removing its check for writability. |
|
Fine with me, though let's only remove the writability check. As you said above, the test is otherwise fine, and it may help us catch other problems sometimes... |
Don't check writability in test for get_home_dir when HOME is undefined Some pathological environments such as gentoo sandboxes can give invalid results. The code path is at least executed, but no values are checked. closes ipython#1998
Some pathological environments such as gentoo sandboxes can give invalid results. closes ipython#1998
Don't check writability in test for get_home_dir when HOME is undefined Some pathological environments such as gentoo sandboxes can give invalid results. The code path is at least executed, but no values are checked. closes ipython#1998
The text was updated successfully, but these errors were encountered: