Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BLD: distutils does not gracefully handle separate Windows Drive Paths #12530

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.

Sign up for GitHub

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

Jump to bottom
Closed
tylerjereddy opened this issue Dec 11, 2018 · 7 comments · Fixed by #16308
Closed

BLD: distutils does not gracefully handle separate Windows Drive Paths #12530

tylerjereddy opened this issue Dec 11, 2018 · 7 comments · Fixed by #16308
Labels
component: build

Comments

@tylerjereddy
Copy link
Contributor

Building NumPy from source on a Windows path that starts from a different drive letter from the library paths causes a traceback as shown below. One might generally assume this is a bad idea, but it is the exact scenario currently present for Windows images on Azure (I use the -n flag to runtests.py to circumvent this, but this may prevent the junit xml file from containing build info, which may be causing one of the two Windows warnings observed there at the moment; the other warning I've patched in my fork already).

2018-12-11T03:39:18.5547666Z Traceback (most recent call last):
2018-12-11T03:39:18.5548033Z   File "setup.py", line 411, in <module>
2018-12-11T03:39:18.5548537Z     setup_package()
2018-12-11T03:39:18.5548982Z   File "setup.py", line 403, in setup_package
2018-12-11T03:39:18.5549353Z     setup(**metadata)
2018-12-11T03:39:18.5549758Z   File "D:\a\1\s\numpy\distutils\core.py", line 171, in setup
2018-12-11T03:39:18.5550129Z     return old_setup(**new_attr)
2018-12-11T03:39:18.5550540Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\site-packages\setuptools\__init__.py", line 143, in setup
2018-12-11T03:39:18.5551173Z     return distutils.core.setup(**attrs)
2018-12-11T03:39:18.5551590Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\distutils\core.py", line 148, in setup
2018-12-11T03:39:18.5551960Z     dist.run_commands()
2018-12-11T03:39:18.5552336Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\distutils\dist.py", line 966, in run_commands
2018-12-11T03:39:18.5552725Z     self.run_command(cmd)
2018-12-11T03:39:18.5553189Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\distutils\dist.py", line 985, in run_command
2018-12-11T03:39:18.5553718Z     cmd_obj.run()
2018-12-11T03:39:18.5554097Z   File "D:\a\1\s\numpy\distutils\command\build.py", line 47, in run
2018-12-11T03:39:18.5554485Z     old_build.run(self)
2018-12-11T03:39:18.5554860Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\distutils\command\build.py", line 135, in run
2018-12-11T03:39:18.5555342Z     self.run_command(cmd_name)
2018-12-11T03:39:18.5555739Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\distutils\cmd.py", line 313, in run_command
2018-12-11T03:39:18.5556146Z     self.distribution.run_command(command)
2018-12-11T03:39:18.5556527Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\distutils\dist.py", line 985, in run_command
2018-12-11T03:39:18.5556912Z     cmd_obj.run()
2018-12-11T03:39:18.5557283Z   File "D:\a\1\s\numpy\distutils\command\build_ext.py", line 261, in run
2018-12-11T03:39:18.5557669Z     self.build_extensions()
2018-12-11T03:39:18.5558066Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\distutils\command\build_ext.py", line 448, in build_extensions
2018-12-11T03:39:18.5558439Z     self._build_extensions_serial()
2018-12-11T03:39:18.5558844Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\distutils\command\build_ext.py", line 473, in _build_extensions_serial
2018-12-11T03:39:18.5559251Z     self.build_extension(ext)
2018-12-11T03:39:18.5559627Z   File "D:\a\1\s\numpy\distutils\command\build_ext.py", line 467, in build_extension
2018-12-11T03:39:18.5560009Z     unlinkable_fobjects)
2018-12-11T03:39:18.5560406Z   File "D:\a\1\s\numpy\distutils\command\build_ext.py", line 512, in _process_unlinkable_fobjects
2018-12-11T03:39:18.5560802Z     fobjects = [os.path.relpath(obj) for obj in unlinkable_fobjects]
2018-12-11T03:39:18.5561184Z   File "D:\a\1\s\numpy\distutils\command\build_ext.py", line 512, in <listcomp>
2018-12-11T03:39:18.5561561Z     fobjects = [os.path.relpath(obj) for obj in unlinkable_fobjects]
2018-12-11T03:39:18.5561974Z   File "C:\hostedtoolcache\windows\Python\3.7.0\x64\lib\ntpath.py", line 564, in relpath
2018-12-11T03:39:18.5562363Z     path_drive, start_drive))
2018-12-11T03:39:18.5562726Z ValueError: path is on mount 'C:', start on mount 'D:'
@tylerjereddy tylerjereddy mentioned this issue Dec 11, 2018
Closed
@mattip
Copy link
Member

mattip commented Dec 12, 2018

We could change that to abspath instead, at least on windows

@mattip mattip mentioned this issue Dec 12, 2018
Closed
rgommers added a commit to rgommers/scipy that referenced this issue May 1, 2020
@rgommers
BLD: fix Azure CI issue related to relpath on different drive letters
6fa9190 
See numpy/numpy#12530
rgommers added a commit to rgommers/scipy that referenced this issue May 1, 2020
@rgommers
BLD: fix Azure CI issue related to relpath on different drive letters
5efaacb 
Closes scipygh-11967, see also numpy/numpy#12530
@rgommers rgommers mentioned this issue May 1, 2020
Closed
@rgommers
Copy link
Member

rgommers commented May 1, 2020

This is unfortunate, we should have merged @mattip's PR in one form of another. I'll see if scipy/scipy#11990 fixes the SciPy issues, and if so will submit the same fix here - much better than continuing with the Azure config file.

@eric-wieser eric-wieser mentioned this issue May 1, 2020
Closed
@seberg
Copy link
Member

seberg commented May 1, 2020

Should we just revive that PR and simply risk exchanging a known issue with only a hypothetical issue due to the inability to test things perfectly?

@rgommers
Copy link
Member

rgommers commented May 1, 2020

I think the try: old_thing - except: try_harder that @eric-wieser proposed is better, that definitely can't break anything that's working now.

@rgommers
Copy link
Member

rgommers commented May 1, 2020

But yes, +1 for not requiring test perfection.

@anirudh2290
Copy link
Member

just revisiting this, can we do something like : sphinx-doc/sphinx#4807 where we just use path if os.path.relpath doesn't work, or does it have certain implications with absolute paths being used for certain compilers as @mattip mentions here : #16107 (comment) .

@mattip mattip mentioned this issue May 20, 2020
Merged
@mattip
Copy link
Member

mattip commented May 20, 2020

I revived the older PR in a new gh-16308. I think the fix should remain straight-forward to smoke out possible problems; if we hit a snag we can always do the try: execpt: route but I would like to understand first why/where abspath is the wrong thing to do.

@charris charris mentioned this issue May 30, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: build
Projects
None yet
Milestone
No milestone
5 participants
@seberg @rgommers @mattip @anirudh2290 @tylerjereddy