Request: minified header #105
Comments
|
Thanks @yuhan0 for sharing. It is interesting how people are using the notebook! I had never seen before such big metadata! Interestingly, at the level of cell metadata we face the same problematic (see also #106 ). Certainly the text representation should focus only the metadata that is relevant. A few comments, suggestions and questions:
|
This was referenced Oct 17, 2018
mwouts
added a commit
that referenced
this issue
Oct 22, 2018
mwouts
added a commit
that referenced
this issue
Oct 22, 2018
mwouts
added a commit
that referenced
this issue
Oct 22, 2018
|
Hello @yuhan0 , the branch v0.8.4 contains a first implementation of this:
I would like the following feedback from you:
|
mwouts
added a commit
that referenced
this issue
Oct 23, 2018
mwouts
added a commit
that referenced
this issue
Oct 23, 2018
mwouts
added a commit
that referenced
this issue
Oct 23, 2018
|
Hi, thanks for the quick response and sorry I couldn't get around to replying earlier - the suggestions sound good, except I'm slightly confused about this part:
Does it mean literally to append the prefixes "additonal" and "excluded" to the metadata names? E.g. Is it a good idea to be able to exclude the default sections? Can they be reliably "inferred" if missing or will it possibly lead to strange behaviour? I imagine the "jupytext" section at the least should not be user-excludable. How about using a spec like: {"jupytext": {
"include_metadata": {
"notebook": [],
"cells": []
},
"exclude_metadata": {
"notebook": [],
"cells": []
}
}}where any of the keys can be left out to save space. |
|
Another thought - saved widget state should be treated similarly to cell outputs and always excluded no matter what. And the resulting .py file after widget state was saved: Click to viewOne more thing - how should we go about installing and using the 0.8.4 dev version? Though I may not have the time to test it much.. |
|
Thanks @yuhan0 for your feedback. Indeed the size of the notebook metadata is impressive ! I will soon update the documentation to make it clear how the metadata filtering works in v0.8.4. And please do not bother to install the dev version if that sounds uneasy - let me prepare a new pip release (possibly a release candidate) for v0.8.4, that will be simpler. |
mwouts
added a commit
that referenced
this issue
Oct 24, 2018
|
The pre-release is available with The documentation for the metadata filtering is here. @yuhan0 , that would be very nice if you could test that the RC works well for you, and also, if you could check that the corresponding part of the documentation is not too hard to follow. |
|
Small correction to the docs: metadata title should be 'widgets', not 'widget'
This might be a matter of opinion, but I don't think it's very user-friendly or idiomatic in JSON to overload a single string with multiple attributes by essentially inventing a mini-DSL and dealing with all the edge cases of parsing user input strings. (it's not the Unix command line, after all!) Also I found it highly unintuitive that Maybe it would be less ambiguous to require a with the items in any order. Edit: Just tried out the 0.8.4rc, it seems that simply adding spaces anywhere between items ( Same thing with the "formats" field: it's slightly annoying that |
|
Thanks @yuhan0 , this is a very helpful feedback.
|
|
So the full spec would look like this? (informal choice type notation) Perhaps mutually exclusive options would be more compact and remove the ambiguity of having the same item specified in multiple places: This way the default value can be expressed as (Does it make sense to allow the user to exclude any of these?) My assumption was that an nbextension would be developed sooner or later which would remove the need for the user to manually edit JSON, and it should be more important to make it easy to machine-generate and parse. To address the trouble of typing in JSON lists, there could be a canonicalization step where a user input comma-separated string in a position where a list of strings was expected would be automatically converted and saved as the list format. |
|
Thanks @yuhan0 . Let me see if I can implement the
Another question: do you think the default filtering in the YAML header is good enough? Are you aware of other notebook metadata that users expect to be resilient to |
mwouts
added a commit
that referenced
this issue
Oct 25, 2018
|
Hello @yuhan0 , I just published another pre-release, available with That release includes the support for the metadata filter as dictionaries, as strings, also allows spaces in strings, and has the automated string to dict conversion (the conversion occurs when the notebook is reloaded). Could you please let me know if it works well for you?
If you have any clue on this, please tell me! We are introducing a significant change in 0.8.4 by keeping only |
mwouts
added a commit
that referenced
this issue
Oct 29, 2018
mwouts
added a commit
that referenced
this issue
Oct 29, 2018
mwouts
added a commit
that referenced
this issue
Oct 29, 2018
mwouts
added a commit
that referenced
this issue
Oct 29, 2018
mwouts
added a commit
that referenced
this issue
Oct 29, 2018
mwouts
added a commit
that referenced
this issue
Oct 29, 2018
mwouts
added a commit
that referenced
this issue
Oct 29, 2018
mwouts
added a commit
that referenced
this issue
Oct 29, 2018
|
Available in v0.8.4. |
|
@andrethrill , @yuhan0 , I was thinking of removing the |
mwouts
added a commit
that referenced
this issue
Nov 18, 2018
'language_info' section is not in the text metadata any more. Instead, the notebook language is infered from 'kernelspec.name'.
|
Hi @mwouts , from my side I believe it's alright yes! |
|
Same with me :) Glad to see such active development on this project! |
mwouts
added a commit
that referenced
this issue
Nov 25, 2018
'language_info' section is not in the text metadata any more. Instead, the notebook language is infered from 'kernelspec.name'.
|
Thanks for your feedback! This is available in the new RC. Please let me know if you find anything wrong with it... |
Merged
|
Version 0.8.6 is now available. |
mwouts
added a commit
that referenced
this issue
Dec 12, 2018
Metadata filters are represented as strings rather than dictionaries, in order to make the YAML header shorter.
mwouts
added a commit
that referenced
this issue
Jan 14, 2019
Metadata filters are represented as strings rather than dictionaries, in order to make the YAML header shorter.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With various nbextensions enabled and saved widget state, the size of a header can easily go up to many hundreds of lines.
This produces huge and mostly irrelevant git diffs and makes it inconvenient to skip past all the "commented-out noise" at the start of a paired .py file in order to get to the actual code.
Would it be possible to have a "minified header" formatting option which strips out unnecessary detail and compresses the entire header onto a single line, or one line for every top-level key? My impression was that the header is not meant to be human-edited anyways, apart from the "jupytext.formats" field. Better still, why not dump it in the original JSON format to prevent any round-trip errors?
Thanks so much for this package!
The text was updated successfully, but these errors were encountered: