pv.plotter.export_html Hangs when '-i' option is given to argparse in user script
natsuwater opened this issue · comments
Describe the bug, what's wrong, and what you expected.
I am encountering an issue with the pv.plotter.export_html function in my script. The script uses argparse to handle command-line options. When I pass the -i option, the code hangs with traceback displayed.
Expected Result: The script should generate a vtk.js-powered 3D view in test.html.
Note when I use the long option name --input, the code runs as expected and generates the HTML file.
Also, as far as I’ve tested, it seems that the -i option is causing the issue. When I use a different option name (e.g., parser.add_argument("-j", "--j_input")), the script runs without any problems.
Steps to reproduce the bug.
Set up a virtual environment and install pyvista on Windows 11 using the following command: pip install pyvista[all,trame]
Run the following script: python ./pv_h.py -i test.html
# pv_h.py
import pyvista as pv
from pyvista import examples
import argparse
def generate_image(inoutfile):
mesh = pv.read(examples.planefile)
pl = pv.Plotter(off_screen=True)
pl.add_mesh(mesh)
pl.export_html(inoutfile)
def get_args():
parser = argparse.ArgumentParser()
parser.add_argument("-i", "--input")
args = parser.parse_args()
return args
def main():
args = get_args()
generate_image(args.input)
if __name__ == "__main__":
main()Resulting message:
python pv_h.py -i test.html
ERROR:root:Exception raised by task = <Task finished name='Task-2' coro=<WebAppServer.start() done, defined at C:\Users\natsu\py310_pv_trame\lib\site-packages\wslink\backends\aiohttp\__init__.py:98> exception=gaierror(11001, 'getaddrinfo failed')>
Traceback (most recent call last):
File "C:\Users\natsu\py310_pv_trame\lib\site-packages\trame_server\core.py", line 681, in on_done
task.result()
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\futures.py", line 201, in result
raise self._exception.with_traceback(self._exception_tb)
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\tasks.py", line 234, in __step
result = coro.throw(exc)
File "C:\Users\natsu\py310_pv_trame\lib\site-packages\wslink\backends\aiohttp\__init__.py", line 111, in start
await self._site.start()
File "C:\Users\natsu\py310_pv_trame\lib\site-packages\aiohttp\web_runner.py", line 119, in start
self._server = await loop.create_server(
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\base_events.py", line 1485, in create_server
infos = await tasks.gather(*fs)
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\tasks.py", line 304, in __wakeup
future.result()
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\tasks.py", line 234, in __step
result = coro.throw(exc)
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\base_events.py", line 1422, in _create_server_getaddrinfo
infos = await self._ensure_resolved((host, port), family=family,
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\base_events.py", line 1418, in _ensure_resolved
return await loop.getaddrinfo(host, port, family=family, type=type,
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\base_events.py", line 863, in getaddrinfo
return await self.run_in_executor(
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\futures.py", line 285, in __await__
yield self # This tells Task to wait for completion.
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\tasks.py", line 304, in __wakeup
future.result()
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\asyncio\futures.py", line 201, in result
raise self._exception.with_traceback(self._exception_tb)
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\concurrent\futures\thread.py", line 58, in run
result = self.fn(*self.args, **self.kwargs)
File "C:\Users\natsu\AppData\Local\Programs\Python\Python310\lib\socket.py", line 955, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 11001] getaddrinfo failed
On the other hand, python ./pv_h.py --input test.html generates test.html.
System Information
--------------------------------------------------------------------------------
Date: Tue Apr 16 21:30:55 2024 東京 (標準時)
OS : Windows
CPU(s) : 16
Machine : AMD64
Architecture : 64bit
Environment : Python
GPU Vendor : ATI Technologies Inc.
GPU Renderer : AMD Radeon(TM) Graphics
GPU Version : 4.6.0 Compatibility Profile Context 23.10.24.05.230830
MathText Support : False
Python 3.10.11 (tags/v3.10.11:7d4cc5a, Apr 5 2023, 00:38:17) [MSC v.1929 64
bit (AMD64)]
pyvista : 0.43.5
vtk : 9.3.0
numpy : 1.26.4
matplotlib : 3.8.4
scooby : 0.9.2
pooch : 1.8.1
pillow : 10.3.0
imageio : 2.34.0
IPython : 8.23.0
colorcet : 3.1.0
cmocean : 4.0.3
ipywidgets : 8.1.2
meshio : 5.3.5
trame : 3.6.0
trame_client : 3.0.1
trame_server : 3.0.0
trame_vtk : 2.8.5
trame_vuetify : 2.4.3
jupyter_server_proxy : 4.1.2
nest_asyncio : 1.6.0
--------------------------------------------------------------------------------Screenshots
No response
On Linux, it runs fine and outputs the file. It may be a Windows-specific issue.
--------------------------------------------------------------------------------
Date: Wed Apr 17 07:48:59 2024 JST
OS : Linux
CPU(s) : 20
Machine : x86_64
Architecture : 64bit
Environment : Python
GPU Vendor : Intel
GPU Renderer : Mesa Intel(R) Graphics (ADL GT2)
GPU Version : 4.6 (Core Profile) Mesa 23.2.1-1ubuntu3.1
MathText Support : True
Python 3.11.6 (main, Oct 8 2023, 05:06:43) [GCC 13.2.0]
pyvista : 0.43.5
vtk : 9.3.0
numpy : 1.26.4
matplotlib : 3.8.4
scooby : 0.9.2
pooch : 1.8.1
pillow : 10.3.0
imageio : 2.34.0
pyvistaqt : Version unknown
IPython : 8.23.0
colorcet : 3.1.0
cmocean : 4.0.3
ipywidgets : 8.1.2
meshio : 5.3.5
trame : 3.6.0
trame_client : 3.0.1
trame_server : 3.0.0
trame_vtk : 2.8.5
trame_vuetify : 2.4.3
jupyter_server_proxy : 4.1.2
nest_asyncio : 1.6.0
--------------------------------------------------------------------------------
-i was part of the shorthand in wslink which I removed yesterday.
Oh, it's true. I downgraded wslink to v2.0.0, and the error was reproduced. Thanks @jourdain .
@natsuwater Can we close this?
Yes, indeed.
I've confirmed that with updated wslink, export_html works fine just as expected.
Thank you all for such a quick response.