Split off renderer into its own package about altair

[g3o2]

You probably need to provide a base_url argument because vegawidget won't know where the data (csv or json) is located in relation to the spec. Or maybe it is sufficient to require that the relative path be specified in the spec?

[ijlyttle]

vegawidget is established

[g3o2]

good idea! If vega-embed is going to be used, then both vegalite and vega json specs could be rendered in a browser via R. Such a package would gain a lot of traction.

As of vega-embed 3, the $schema property of vegalite and vega specs are checked for, so major version changes for rendering will be taken care of.

For vega-lite 1 or vega 2 specs, the older, relevant vega-embed 2 version is still available and could be called separately, if so desired.

[g3o2]

Regarding the vega js dependency issue. If you split off the renderer from altair, I think it would be only natural to allow the renderer to move along with the vega js ecosystem and not with Altair. This will allow users to move on to newer json features as they come. This strategy would also require no updating of the dependencies as long as there is no major version change.

However, to allow for a harmonious interaction with the altair package, maybe you could expose an option or a function (e.g. altair_mode) which would then strictly apply the dependencies as required by Altair.

[AliciaSchep]

Since an htmlwidget package needs to have copies of the dependencies included, there will always be some delay with the latest js versions. While including different versions may be possible, I don't think the extra complication plus package size is likely worth it.

[g3o2]

This will probably also depend on how fast Altair will move forward in general. Maybe start out simple and wait for user feedback.

In any case, the versions included should be provided as an exposed function. This is important since the vegalite, vega and vega-embed documentation is not versioned.

[ijlyttle]

I think that we could expose such a function, and it would be helpful - if even for us :)

Starting a list at the top of this thread.

[ijlyttle]

Let's keep the URL issue in mind - I think this is a case, as you point out, where we should have the problem before we solve the problem.