Opened 8 years ago
#808 new defect
view_html failing in the release bundle
Reported by: | pkienzle | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | SasView Next Release +1 |
Component: | SasView | Keywords: | |
Cc: | Work Package: | SasView Bug Fixing |
Description
The 4.0.1 release on Mac does allow users to run sascomp
>>> from sasmodels.compare import main >>> main("cylinder") OCL32 t=1273.96 ms, intensity=126048 OCL64 t=345.82 ms, intensity=126048 |OCL32-OCL64| max:7.286e-04 median:2.687e-04 98%:6.997e-04 rms:3.349e-04 zero-offset:+2.902e-04 |(OCL32-OCL64)/OCL64| max:6.520e-07 median:2.905e-07 98%:6.114e-07 rms:3.368e-07 zero-offset:+3.037e-07
but not view_html
>>> from sasmodels.generate import view_html >>> view_html("cylinder") <string>:: (ERROR/3) Cannot embed stylesheet 'html4css1.css': No such file or directory. Traceback (most recent call last): File "<input>", line 1, in <module> File "/Users/pkienzle/Desktop/SasView 4.0.1.app/Contents/Resources/lib/python2.7/sasmodels/generate.py", line 916, in view_html File "/Users/pkienzle/Desktop/SasView 4.0.1.app/Contents/Resources/lib/python2.7/sasmodels/generate.py", line 908, in make_html File "/Users/pkienzle/Desktop/SasView 4.0.1.app/Contents/Resources/lib/python2.7/sasmodels/rst2html.py", line 94, in rst2html File "docutils/core.pyc", line 448, in publish_parts File "docutils/core.pyc", line 662, in publish_programmatically File "docutils/core.pyc", line 219, in publish File "docutils/writers/__init__.pyc", line 80, in write File "docutils/writers/html4css1/__init__.pyc", line 179, in translate File "docutils/writers/html4css1/__init__.pyc", line 182, in apply_template IOError: [Errno 20] Not a directory: 'lib/python2.7/site-packages.zip/docutils/writers/html4css1/template.txt'
The reason is that the supporting css and template files are in the library zip bundle, and so are not accessible using normal os file I/O.
The documentation already says "developer version only" for this feature, so at least users will not be surprised that it is not working.
Rather than hacking the package so that support files can be loaded from the zip, or otherwise figuring out which support files are needed, storing them separately, and redirecting the package to look in the new location, we could distribute the application like a virtual environment with its own private python interpreter and site-packages directory. This way the packages themselves could manage their own support files using pip install. Once this is set up the release version will be much more similar to the development version, which should mean much fewer instances of something working for developers and not for users.