fix css style #1389
fix css style #1389
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1389 +/- ##
==========================================
- Coverage 91.73% 91.72% -0.01%
==========================================
Files 105 105
Lines 10898 10901 +3
==========================================
+ Hits 9997 9999 +2
- Misses 901 902 +1
Continue to review full report at Codecov.
|
| @@ -696,5 +696,6 @@ class HtmlTemplate: | |||
| </div> | |||
| </li> | |||
| """ | |||
| _, css_style = xr.core.formatting_html._load_static_files() # pylint: disable=protected-access | |||
There was a problem hiding this comment.
I am fine with enforcing the lazy load but we then have to update requirements to xarray 0.16.1 too, otherwise we need and if/else.
There was a problem hiding this comment.
True, what should we do? Have our own css file, or copy the lazy load function?
There was a problem hiding this comment.
I gravitate towards requiring xarray 0.16.1 so this code works without problem or having our lazy load function that calls xarray's one if possible and gets css style otherwise.
There was a problem hiding this comment.
Let's update xarray to 0.16.1
There was a problem hiding this comment.
Just to warn you, this line is definitely using an internal xarray function that could go away or be disabled in the future. That's why you had to add the lint comment to disable protected-access :).
If you are OK copying the CSS file into arViz, that would be my preference for the safest/simplest way to do this (without any chance of things breaking in the future).
Otherwise, if for some reason you need to keep it in sync with xarray's version, we could definitely consider adding a public API option for getting this information from xarray. In that case, please open an issue in xarray's issue tracker.
There was a problem hiding this comment.
Yes, we are using internal function. Until we figure out a good way to solve this, I think we are ok with this solution.
xarray should not (and probably are not) worry changing their internal functionality.
|
We ran into this issue because our project depends on Pymc3, which relies on Arviz. We are going to work around it by locking the version of XArray to before the breaking change. Your solution to rely on yet another private entry point to Xarray is a recipe for another breakage for yours and all dependent packages. Suggest if you need a coupling to XArray that you PR a new public interface to that package. |
|
Ok, I understand. We need a better fix. |
|
So how do we fix it ? |
|
This has been fixed in #1392 |
Description
Change access to css file.
Checklist