2.0.0 #658
2.0.0 #658
Conversation
|
@chriddyp @Kully @cldougl is there any reason for us to support In other words, I'd like to keep our versioning linear if possible, each new version should be a higher number than the last. I suppose we can always change this later by pulling old commits into new branches, etc, etc. Again, I'm suggesting that we merge |
|
I feel like it would be pretty annoying to maintain both branches. I recall a lot of organization stuff (FigureFactory) which won't affect the users' experience and more additions which make 2.0.0 sounds better. |
Yup, it would be. Not supporting multiple, concurrent versions is definitely my vote, but I just want to get consensus on our approach. |
|
+1 for not continuing to support version |
|
Great! Consensus-enough! Then I'm going to merge |
|
Just a couple things that I'm up in the air on:
Seem reasonable? |
|
Okie dokie. Heres' the state of
I'll version-bump when all that's through ;) |
In general, we have cyclic import issues all over the place, this is one easy fix and will help out in later commits. Note that this maintains backwards compat due to how the the functions are imported into `plotly.py`.
This is also some setup for a larger refact. Since v1 and v2 requests handle errors differently, it’s easier if we simplify the api into our errors so that the requests can go from `response` —> `python error` as they see fit.
This was driving me nuts. We basically manually handle creating and validating *each* api response inside each calling function. Even worse, we *sometimes* raise a `PlotlyRequestError` and *sometimes* just bubble up the `requests.exceptions.HTTPError` ;__;. This does the following: * Define an `api.v1` module that only includes `clientresp` (the only old api method we still *need* to cling to) * Define an `api.v2` module that includes all the new functionality of our v2 api. * Both `v1` and `v2` raise the same `PlotlyRequestError`, so that users only need to catch *one* exception class in scripts.
Note that the `apigetfile` did some weird things to convert old-style plotlyjs figures (e.g. `type: ‘histogramx’`) to new-style versions. I wanted to ween us off the old api, so this makes the change from `/apigetfile` —> `/v2/plots/[fid]/content?inline_data=true`. The `_swap*` functionality was copied from `plotly/streambed` code, directly from the backend’s implementation of `apigetfile`.
There is a circular import issue that needed to be fixed here as well.
This is allowed when setting the credentials *file*, however, trying to set this inside a session used to fail.
The `requests` package kindly manages 2/3 compat for json for us, might as well be consistent and use the same tool! As a side note, I’d like to move away from `six` and depend directly on `requests.compat`. I believe it has everything we need and then we can ditch the `six` dep and know that we’re always in sync with whatever requests is doing (which is really what we care about).
The old location is now deprecated.
Ok the changes in default args are more than style changes… Just a heads up.
This is a stand-alone module to do the following: * Don’t import optional things until we need them * Keep all the optional imports centralized
I can’t believe that this wasn’t tested anywhere before!
Note that we don’t necessarily *require* `numpy` for in all the FF methods. We’re just looking to make the compatibility-breaking change so that we can depend on it in `2.0.0`. Also note that I’d forgotten to include `figure_factory` in setup.py before ;__;.
|
no reservations! |
|
OK, done waiting, I think the next step needs to be manual testing. Merge time! |
Aight, we're set to merge this. I'm going to ask for a final round of review and then merge and setup a
pre-releasefor this before I push anything new up to PyPI.Closes #642