These are chat archives for ipython/ipython

15th
Nov 2016
Min RK
@minrk
Nov 15 2016 10:02
@SylvainCorlay ~= is equivalent, I think.
Not quite
Or rather, ~= 1.2 is equivalent. to ^1.2.3, but ~= 1.2.0 is not
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 10:04
thanks
@minrk I am working on a jsonschema spec for the serialized widget state
Min RK
@minrk
Nov 15 2016 10:04
comparing this to this.
cool!
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 10:05
{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "description": "Jupyter Interactive Widget State JSON schema.",
    "type": "object",
    "additionalProperties": true,
    "additionalProperties" : {
        "type": "object",
        "properties": {
            "model_name": { "type": "string" },
            "model_module": { "type": "string" },  // AMD loadable module for model implementation
            "model_module_version": { "type": "string" },  // semver range for model module
            "state": {
                "type": "object",
                    "additional_properties": true
            },
            "views": {
                "type": "array"
            }
        },
        "required": ["model_name", "model_module", "state"],
        "additional_properties": false
    }
}
I just wonder where I should put it
Min RK
@minrk
Nov 15 2016 10:05
The widgets schema?
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 10:05
and if I should add a version number
yes
it is more of a documentation thing even though it actually validates the thing
Min RK
@minrk
Nov 15 2016 10:06
It depends a little bit on how you want to use it.
If it's mainly documentation/reference, you can put it in the widgets docs.
If you want code to validate it, you'll want to distribute it with the code
e.g. nbformat validates on read/write, so it's in the package.
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 10:07
This schema is used (unvalidated) for embedded widgets.
It will also be used for the sphinx extension.
Now we can generate the spec from both the frontend and the back end
And I guess this would be important for kyle's server-side models
I am just asking in case there is any lessons learned from nbformat, on pitfalls I could avoid
Min RK
@minrk
Nov 15 2016 10:18
Definitely version the spec
Min RK
@minrk
Nov 15 2016 10:26
I think ~everything has gone fine witht the nbformat spec in terms of the schema and how it's distributed. It's useful to version the spec independently of the package, since we can update the Python API without updating the spec and vice versa.
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 10:40
Thanks. I am on it
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 13:21
@minrk @jasongrout do you guys think that the sphinx extension for ipywidgets deserves its own repository?

My concern about the ipywidgets repo is that it has already

  • ipywidgets python package
  • jupyter-js-widget npm package

  • embedder npm package

  • jupyterlab_widgets python + npm package

  • widgetsnbextension python + npm package
Jason Grout
@jasongrout
Nov 15 2016 14:04
so the pattern is clear - every package dealing with ipywidgets should be in the ipywidgets repo :)
how big is the sphinx extension?
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 14:26
not big
but I find the ipywidgets repo too big
Min RK
@minrk
Nov 15 2016 14:42
I'm not sure, there's a cost both ways.
The main benefit of pulling it out is being able to release versions independently of widgets versions.
If there should be coordination of versions, splitting it only makes it harder.
My feeling after a year of split is that I really wish widgets javascript was served by the kernel, from the Python package.
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 17:38
Yeah, the thing is that the multiplication of packages within ipywidgets makes things confusing for potential newcomers
Are you ok with me creating a jupyter-widgets-sphinx repo in jupyter?
Sylvain Corlay
@SylvainCorlay
Nov 15 2016 17:45
@minrk ok to merge the ipykernel PR?