DEV: use abspath on windows #12535
DEV: use abspath on windows #12535
Conversation
|
Hmm. 32 bit builds are failing. Should they be using
2018-12-12T09:39:01.2324286Z error: Command "C:\tools\mingw64\bin\gfortran.exe -Wall -g -Wall -g -shared -Wl,--whole-archive C:\hostedtoolcache\windows\Python\3.6.4\x86\lib\openblas.a -Wl,--no-whole-archive -LC:\tools\mingw64\lib\gcc\x86_64-w64-mingw32\5.3.0 -LC:\hostedtoolcache\windows\Python\3.6.4\x86\libs -LC:\hostedtoolcache\windows\Python\3.6.4\x86\PCbuild\win32 -Lbuild\temp.win32-3.6 -o build\temp.win32-3.6\Release\.libs\libopenblas.JKAMQ5EVHIVCPXP2XZJB2RQPIN47S32M.gfortran-win32.dll -Wl,--allow-multiple-definition -Wl,--output-def,build\temp.win32-3.6\Release\libopenblas.JKAMQ5EVHIVCPXP2XZJB2RQPIN47S32M.gfortran-win32.def -Wl,--export-all-symbols -Wl,--enable-auto-import -static -mlong-double-64" failed with exit status 1
|
891e078 to
5f8ba05
Compare
|
The 2->1 warnings thing appears to be happening on other recent PRs now too -- perhaps on Microsoft's end then for that matter. |
5f8ba05 to
72762e5
Compare
| # relpath fails if we are on a different drive | ||
| fobjects = [os.path.abspath(obj) for obj in unlinkable_fobjects] | ||
| else: | ||
| fobjects = [os.path.relpath(obj) for obj in unlinkable_fobjects] |
There was a problem hiding this comment.
Alternatively - do we want to define:
def relpath_safe(p):
try:
return os.path.relpath(p)
except ValueError:
# on windows, caused by different drive letter
return os.path.abspath(p)That means that in cases where it's safe, we can continue to use relative paths
There was a problem hiding this comment.
We don't actually test the alternate drive scenario since we are using -n, so I am hesitant to put in more complicated untested logic. At some point Python could decide to change the exception to a different error and we would never know. Perhaps we should just always use abspath?
There was a problem hiding this comment.
Perhaps we should just always use abspath?
It's hard to say without knowing the original rationale for the relative paths.
I think it's incredibly unlikely that python changes the exception type in future, and if they do, I'd hope they'd just create a subclass of ValueError, like they did when they changed IOError
|
I do not see this line being hit in tests on linux64. @tylerjereddy which test or build step hit this issue? |
|
I don't think we ever really have much expectation that distutils code paths are covered by tests; the only scenario where this has been an issue is on Azure pipelines windows jobs when For whatever reason the pip build / wheel installs are not prone to the drive path issue. I'm not sure what the best course of action is--I think it is becoming increasingly common to recommend usage of pip for installs on Windows. I originally thought this matter was perhaps higher priority because of the build-related Warnings on Windows builds, but we've now heard back from Microsoft that this is likely something on their end and not anything to do with runtests.py |
|
Closing this since I cannot verify that the new code path is correct |
|
The only platform where this matters is on Windows, so it's sufficient to test on Windows. |
|
It sounds like we may want to revisit this, using Eric's try/except approach to be conservative. I guess we can't auto-reopen the PR because the branch was deleted. |
|
I'd probably vote against my suggestion above - chance are it either always works on absolute paths, or it never does. We've a greater chance of someone telling us how we got it wrong if we just use them always. |
|
|
Fixes #12530 where having build artifacts on different drives prevents use of
os.path.relpath