Change id generation to be hash based to avoid problematic word combinations #217
Conversation
|
We talked about this yesterday in the Jupyter Notebook meeting and our thinking aligned with this PR for the reasons stated. @jasongrout @blink1073 @afshin |
docs/changelog.rst
Outdated
| @@ -7,6 +7,11 @@ Changes in nbformat | |||
| In Development | |||
| ============== | |||
|
|
|||
| 5.1.2 | |||
There was a problem hiding this comment.
5.1.2 is already released. The next one would be 5.1.3.
There was a problem hiding this comment.
Good catch. I'll fix that later this afternoon.
|
Thanks for the quick reviews everyone. I've pushed the release tag for this and 5.1.3 should finish building shortly. |
|
The NPM Publish failed because the token was rejected. I refreshed the token and manually pushed the npmjs version (though it has no actual JS changes). I think it's incorrectly expecting an OTP token despite the auth key being an automation key that's not support to ask for it.... will keep an eye out on it next time there's a tag publish to see if it fails again. |
|
From what I can see, this fix was released in version 5.1.3 of nbformat. Does it make sense to "yank" (this is the technical term pypi uses for this) the 5.1.2 version to prevent people from accidentally installing the older version? |
|
@ellisonbg I think it makes sense, yes. Done, however I wasn't sure how to approach the conda-forge side of things. I posted conda-forge/admin-requests#257 to see if there was a recommended approach there. |
|
@MSeal thanks, not sure how these things work with conda myself. |
Implements Option C from the original JEP to resolve #216 where it was raised that our word generation scheme results in highly problematic word combinations. Until we have a wordlist we feel is safe to use in generating IDs, this will be the source of unset ids detected by nbformat.
I'm going to cross post to jupyter/enhancement-proposals#62 and leave this open for ~24 hours so there's a chance for any additional input before we release. I recognize this pattern choice was not chosen in the original JEP and therefore is subverting the decision therein somewhat without all of the original reviewer's inputs, but the severity of the issue warrants action and there's enough consensus on the issue thread from active folks in the community that this seems a warranted step to avoid the potential insensitive to the nature of the generated ids.