COMPAT with 0.16.0

[jreback]

if someone would like to put all of the accumulated changes since @hayd pulled this from master as a PR back into pandas would be appreciated.

I think a good idea would be to have pandas-datareader, the 0.1 (or whatever version), be released about the same time as 0.16.0 (target at end of feb). We'll put up an announcement in the pandas release about this, and about future availability..

[jorisvandenbossche]

+1
Only one thing, I don't think it should be necessarily at the same time. To say, can also already release a 0.1 now (or in some weeks if there are still some bug reports people are working on. Certainly if some people already want to start working on new features, like the requests from @femtotrader). And then just say when pandas releases that what is in pandas is equivalent with pandas-datareader 0.1

[jreback]

right. I just want to be sure there is a version of pandas-datareader that is completely the same as what 0.16.0 will release.

[davidastephens]

@jreback Sure, I'll do that.

[hayd]

I was able to check the diff of the files (web.py and data.py) against the respective files in pandas, and this diff should just be imports (IIRC). Worked a treat. (Same thing for the test files.)

[davidastephens]

I've marked the commit that was the same as pandas v0.16.0 as v0.1.0.

A couple questions:

• Should we announce this anywhere?
• Should we keep pandas.io.data in-sync from this point forward?

[hayd]

As I've said before, I think we should make pandas-datareader a soft dependancy of pandas. and change the pandas/io/data.py to from pandas_datareader import data, etc, this will keep it insync when the user updates pandas-datareader. This should be post 0.16.final. datareader tests should remain in pandas for the foreseeable.

(It would also help to do the same with pandas-compat... otherwise we can just copy it into pandas_datareader, since that's the thing which breaks pandas-datareader on 0.12-... compat is a part of the pandas codebase that is both useful and stable.)

Not sure if this was agreed on in pandas-dev/pandas#8961 ??

[jreback]

I agree with @hayd here; We will schedule this for 0.17.0. In the meantime, I think pandas-datareader can move at its own pace. The only thing I would ask is if you need/want to change the API, then we would recommend the compat version (for 0.17.0) at least.

@dstephens99 as far as releases go.

I would:

• send out an announcement, here is the pandas release checklist, which is much more complex because of all of the extensions and platform dependencies. pandas-datareader is straightforward in that its a python only package
• upload to pypi
• docs; prob consider moving to readthedocs, its really easy, and builds on pushes from github (it DOES work with non-built dependencies, e.g. you can use numpy/pandas etc for it).

[hayd]

Usual pandas rules then: extend the api (for great good) but don't break it.

Can we add to the checklist: add the rc-release to pandas-datareader's .travis.yml (to trigger the tests)... Is an RC available via conda??? #5

[jreback]

conda should be up soon

[jorisvandenbossche]

about the docs, I had a PR starting with that, I will try to finish that this weekend, unless someone beats me to it

[davidastephens]

Started a release checklist for pandas-datareader here (based on the pandas one).
https://github.com/pydata/pandas-datareader/wiki/Release-Checklist

Added @hayd 's comment on adding rc-release to .travis.yml

[hayd]

To clarify, my comment was for during the pandas release cycle (e.g. when 0.17.0rc comes out, check that build passes the pandas-datareader tests - e.g. test locally and add the newer version of pandas to pandas-datareader's .travis.yml).

I think the release checklist for pandas-datareader can be a lot shorter than pandas! :) e.g. No need for release candidates... "fixed some bugs -> ship a release"... ?

---

One thing I would say to check backwards compat, is that you can run the old tests from pandas:

from pandas.io.tests import test_data
# nose.runmodule(test_data)  # not the right syntax, but I recall doing this in the past..

....This is probably doomed to failure (due e.g. to numbers changing).