Rich, HTML representations for Jupyter Notebook #573
Conversation
moradology
changed the title
|
In the above screenshot, |
moradology
force-pushed
the
feature/html-repr
branch
from
c9502c9 to
ff92065
Compare
Codecov Report
@@ Coverage Diff @@
## main #573 +/- ##
==========================================
- Coverage 94.67% 94.60% -0.07%
==========================================
Files 75 77 +2
Lines 10732 10751 +19
Branches 1048 1048
==========================================
+ Hits 10160 10171 +11
- Misses 396 404 +8
Partials 176 176
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Thanks for working on this @moradology , I like the idea of having these rich representations for contexts like Jupyter.
My biggest concern with this approach is adding jinja2 as a dependency. PySTAC has been extremely careful about not adding non-essential dependencies (see this comment from @lossyrob that gives some good rationale for this), and since jinja2 is only being added to support a narrow set of features I don't feel that it's worth breaking that tradition.
I'm wondering if this kind of functionality would be better in a separate library (e.g. pystac-jupyter, pystac-html, etc.) that could provide more specific support in these environments. If we do want it in PySTAC, I think we should try to accomplish this through a combination of factory functions and f-strings instead of adding a new dependency.
|
After writing this, reading your comment and a very brief discussion with @lossyrob, I'm inclined to agree that adding 1/4th more dependencies(!) is probably not wise. I'm not a huge fan of the f-string approach as it stands to add some clutter to already rather large classes and jinja templates are awfully convenient by comparison. Ironically, the f-string approach has fewer downsides within an external project focused on ergonomics inside the Jupyter context. My vote for preserving this kind of functionality - and I do think it is valuable for those who like to develop and to produce learning materials with Jupyter - would be to extend the primary |
|
I'd agree that creating a Noting that @mmcfarland pointed to these docs previously, which allows you to set custom formatters for types and would probably be useful here https://ipython.readthedocs.io/en/stable/config/integrating.html#formatters-for-third-party-types |
|
@moradology Are you okay with me closing this PR since it sounds like this will be implemented as a separate library? |
|
Very |
Starting point is stac-utils#573 Improvements - Jinja dependency is optional, otherwise __repr__ is used - Catalog shows children - get_items() is kept lazy - Minor improvements in the Jinja templates
* Add rudimentary optional _repr_html_() Starting point is #573 Improvements - Jinja dependency is optional, otherwise __repr__ is used - Catalog shows children - get_items() is kept lazy - Minor improvements in the Jinja templates * Refactor Jinja templates, Assets show title - Use macros to simplify Jinja templates - Assets show title before expansion * All pre-commit checks pass * Jinja templates are distributed with the package Tested by building a wheel (python -m build) after a pip install build creating a new virtualenv installing from the built wheel in the new virtualenv installing jupyter notebooks and testing the html repr * Jinja is imported lazily at the first _repr_html_ call Previously, importing pystac would attempt to import jinja This means jinja would be imported even if the html repr was never used * REF: Separate out Catalog and Collection templates * Style: All list <detail>s have identical margins * Refactor: Collection template inherits from Catalog * Remove unused parameter * Add provider template * Catalog-derived templates use class name as title * Add PR link to changelog * WIP: HTML repr does not retrieve all children&items * Remove accidentally commited notebook * Formatting (black) * Refactor: Limit try/except scope * Mypy ignores optional dependency jinja2 jinja2 is used for optional html_repr for Jupyter Notebooks and should thus not be required * Moving unreleased PR from 1.4.0 to unreleased * ItemCollection implements _repr_html_ * ItemCollection only shows at most 10 items ItemCollection could theoretically have hundreds or thousands of items which shouldn't all be shown in the HTML representation at once Co-authored-by: Jon Duckworth <[email protected]> Co-authored-by: Pete Gadomski <[email protected]>
Related Issue(s): #508
Description:
This PR is intended to provide useful HTML representations of some core STAC objects as well as a structure appropriate to adding more such representations. These are primarily used within Jupyter notebooks, but could in principle find use elsewhere.
PR Checklist:
pre-commit run --all-files)scripts/test)