-
Notifications
You must be signed in to change notification settings - Fork 949
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.
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
DOC: Clean up settings #2660
DOC: Clean up settings #2660
Conversation
Note: The "weather map" example is not included in the It should probably be added to the If this is not desired, it should be added to |
I think I would vote against including the weather map since it brings in pandas and ipyleaflet. My feeling is that we already struggle to maintain the docs (people who spend more time than me doing this like Jason or Matt should chime in here if I'm wrong), so any additional complexity should be weighed very carefully. In this case, I think the extra burden of keeping this page working is not sufficient to justify keeping it in the docs. We could migrate it to a stand-alone GitHub gist, for instance? I'd be happy to do that if that's useful. Alternatively, we can keep it and exclude it from the build. The rest of the changes look good! I made a few comments inline. |
I'm not too worried about the dependencies; each is a well-used package that should install without conflicts. It would be nice to add some more explanatory text to the example, but that is a separate issue. |
And this is a problem why? [UPDATE: I saw @mwcraig's comment above (#2660 (comment)) after sending this one initially.]
I'm not arguing against that, that's your (the project's maintainers) call. But adding a notebook that's already in the repo to the rendered documentation IMHO doesn't add complexity. Therefore, I don't see a reason to delay this PR. If you (the maintainers) decide to remove the weather map notebook (or any other notebooks) from the repo, you can do that in a separate PR. |
@pbugnion -- can I merge this? I see there are a flurry of PRs and don't want to generate merge conflicts unnecessarily... |
Sounds good, thanks for clarifying.
Building the docs directly on this branch fails, because it's missing the fixes in this PR. The CI tests passed on this when it was first submitted because they ran with a now obsolete I think I'd feel most comfortable with:
@mwcraig obviously happy to defer to you if you think that's overkill. |
OK, @mgeier -- would you like to do the rebase or shall I? |
@mgeier -- thanks for this, I'm going to rebase and then merge once tests pass. |
Is there a way to change the Docs test so that it does not use Python 3.5? That goes EOL in several months and it seems like we should be using something newer. I'm not 100% sure yet that an old python version is the issue... |
That sounds sensible. AFAIK, you just need to change the Python version here: Happy to do this tomorrow if that's useful. |
I'll give it a try today and see if it helps, thanks |
@mgeier -- any idea what might be causing this failure? |
I've never seen this error. I can probably take a closer look tomorrow. |
@mwcraig Seems like the method I don't know how this can be fixed. |
Good catch, and @jasongrout noted here that this would affect ipyleaflet. What about allowing errors in this notebook for now? I'm opening an ipyleaflet issue (jupyter-widgets/ipyleaflet#457) -- perhaps @martinRenou can fix it 😀 ? |
In the interest of moving this forward, I'm going to:
The fact that we caught this here argues in favor fo including it to me -- we obviously can't test every downstream package, but some limited testing against ones in the |
0d434ba
to
2ebbf0c
Compare
See #2663 for the issue reminding us to re-enable the notebook once ipyleaflet is updated. |
Also, thanks @mgeier for your fixes here! |
Nice, thank you for pushing this through! |
Thanks @mgeier ! |
Thanks y'all! |
No description provided.