Change default chart width from 400 to 300 #2785
Conversation
|
I think its good to get the approval of @joelostblom here. Just a note: I find myself very often removing the following definition from the generated Vega-lite specification by Altair: "config": {"view": {"continuousWidth": 400, "continuousHeight": 300}}, |
|
Looks good to me overall, but does it make sense to change this in the v3 and v4 versions as well or should we consider them as "frozen" unless we decide to make another 3.x or 4.x point release? |
|
I'd find it a bit more intuitive as a user if we also do it for v3 and v4 as other features are usually also applied to those. these folders are not a snapshot of Altair 3 and 4 but instead of the corresponding vega-lite schemas. |
|
Hmm maybe I am thinking about this wrong, but wouldn't we in general want to avoid adding new altair features to the old schemas because we might add something in altair that would rely on new Vega-Lite functionality that would not be available in the old schemas and therefore potentially cause an error? At least this was the thinking I had when I remove the re-generation of the old schemas as part of https://github.com/altair-viz/altair/pull/2795/files#:
The other side of this I guess is that unless we decide to make a new release of 3.x or 4.x, users would not be able to benefit from any updates we make, so what is the benefit of adding these updates also to the old schemas? |
|
Ah I wasn't aware of that change, thanks for the screenshot! Honestly, I have never seen a use case so far where the old schemas were used and so I don't know what users are expecting from those folders. I can see your point about new vega-lite functionality being introduced. I'm reverting again the changes to v3 and v4 but let me know if you want to keep it after all. |
|
While I don't use it as such, sometimes you see: import altair.vegalite.v3 as alt # or .v4 as altThis approach is also documented https://altair-viz.github.io/user_guide/importing.html#importing-vega-vega-lite-versions (I noticed the page has been updated already in the main repository). |
|
Indeed. When would you actually use this over simply installing an older version of Altair? Maybe if you somehow still need to produce based on an old VL version but a new version of Altair contains a useful bugfix? But what if that bugfix is now no longer applied to v3 and v4 based on the changes to Furthermore, v3 and v4 are not truly frozen as they import both from Maybe this is too bold but in case
what about removing previous version folders completely? It would simplify the maintenance of Altair. |
|
Good points @binste! Thanks for raising and not at all too bold. The altair repository has naturally evolved with both vega and vega-lite-schemas. It is attempted to keep up with these changes by writing python code that can handle any version of the schemas, including vega-lite v1, v2, v3, v4 and now v5. From a technical perspective it's hard, but it is also a great achievement to make this all work. From a maintenance perspective it's just hard. I'm not sure exactly what was the rationale from @joelostblom to introduce the breaking changes by not backporting anything here https://github.com/altair-viz/altair/blob/master/tools/generate_schema_wrapper.py#L32 From a user perspective you could gradually adopt to new features and functionality. Maybe one person write altair code as a python developer/data scientist where the generated vega-lite is feed into a web-application maintained by a front-ender which is still on a certain version of Vega/Vega-lite because it has to maintain new and also legacy code. Personally I would favour that the new release of Altair is able to generate vega-lite specifications that can match both version 4 and version 5 of Vega-lite (not against deprecating the Vega-lite schema v3), especially with these changes from selection to parameters. If that means that one can create vegalite vl4-style-json using this method-syntax with the new release of altair, that would be fine isn't it? Or I'm missing something here? |
|
I will start by saying that I don't feel too strongly about this so if both of you are on board with keeping v4 (and maybe just removing the v3 folder), then I'm on board with that and we can add it back here https://github.com/altair-viz/altair/blob/master/tools/generate_schema_wrapper.py#L32. From my end, I still don't quite see the benefit of keeping any of the old versions around. It does seem like the best way to keep compatibility with an older version of vega-lite is to install an older version of Altair (or maybe specify a specific VL version to vl-convert?). I also quite don't understand what keeping older versions around means for adding new functionality. Should we always add it it in multiple places? Take #2732 for example, should that change have been added to
I think my initial thinking when I did that was that we didn't want users using Altair 4.x to get unwanted new features, but I realize that this will not happen unless they actually install Altair 5.x. Although I still don't quite understand the benefit of keeping the old versions around I'm ok with reverting this change if you think it is too drastic. |
|
Great inputs! My understanding now is that we have two viable options
I slightly favour option 2, as I think also @joelostblom does, but maybe I don't see all the use cases which speak for option 1.
@mattijn Could you elaborate on why the changes from selection to parameters would speak for keeping version 4 around? Is it so that users can install Altair 5 but still use the code for their interactive v4 charts based on selections by importing the v4 version from Altair 5? Wouldn't it then be simpler for them to never upgrade in the first place? |
|
It always has been presented as such,
So for me, to follow this logic is fine:
But the real story was and still is a bit different. There was also always some backward support for the previous VL version and support for Vega version(s). See the following table:
As you can see, most of the time there were multiple versions of Vega-Lite and Vega supported. Maybe the time has come to do the same for Vega-Lite. But be clear why, because I'm not sure if the argument of breaking changes hold. It will reduce maintenance that is for sure. Maybe the time has come as well to drop support for Vega completely? Since you can use vl-convert to render Vega as svg/png. I'm not sure if vl-convert validates the specification too. I meant the following with selection and parameters: one can write the same Altair specification, where it creates different type of Vega-lite specification, just by defining which vegalite version you like to use. from vega_datasets import data
cars = data.cars.url
import altair.vegalite.v5 as alt
alt.Chart(cars).mark_point().encode(
x=alt.X('Horsepower:Q'),
y=alt.Y('Miles_per_Gallon:Q')
).interactive().to_dict()
import altair.vegalite.v4 as alt
alt.Chart(cars).mark_point().encode(
x=alt.X('Horsepower:Q'),
y=alt.Y('Miles_per_Gallon:Q')
).interactive().to_dict()
Here can be seen that the v5 now uses This might be unwanted in some cases (maybe a follow-up pipeline expect I think therefor people also use something as (btw, Vega-lite v5 has still support for Again, I'm OK with including support for a single VL version (and I think even with no version of Vega). |
|
Its not really 'again', but more like, 'I could live with'. |
|
The table is very helpful! Did you create it based on the repo history/CHANGELOG.md or is this available somewhere? My goal with the comments below is not to convince anyone, I think the two of you have a much better understanding of how the package is currently used then I do. I'll just try to provide some more food for thought in case it helps you in making a decision:
import vl_convert as vlc
vl_spec = r"""
{
"$schema": "https://vega.github.io/schema/vega-lite/v5.json",
"data": {"url": "https://raw.githubusercontent.com/vega/vega-datasets/next/data/movies.json"},
"mark": "circle",
"encoding": {
"x": {
"bin": {"maxbins": 10},
"field": "IMDB Rating"
},
"y": {
"bin": {"maxbins": 10},
"field": "Rotten Tomatoes Rating"
},
"size": {"aggregate": "count"},
"unknown_channel": {"maxbins": 10}
}
}
"""
vg_spec = vlc.vegalite_to_vega(vl_spec)
|
From the repo history. I used the tags of each released version to check the generate schema wrapper. Now we have a nice overview, useful for discussions. I opened this issue to continue this discussion further #2817 or start a PR against. |
|
I am going to merge this in. There are several PRs that have been adding new functionality only to VL 5, so if we want to support VL4 we will need to go through the recent PRs (including this one) and add the corresponding functionality to the v4 folder. Thanks for all the great discussion of which versions to support in Altair 5, I think we can continue that in #2817. |
Closes #2581