Travis build fails for Conda package

[tswast]

See: https://travis-ci.org/pydata/pandas-gbq/jobs/392794382

Per https://github.com/conda-forge/staged-recipes/wiki/Namespace-packages, I think we'll probably need to create some empty google-namespace and google-cloud-namespace Conda packages.

Applying my previous fix of locking the miniconda version didn't work this time. (#187)

[max-sixty]

Do other libraries face this?

I've been off the pandas-gbq contribs for a while, but would be up for having a passing build - not a great encouragement for users & contributors I think. Happy to dive in

[tswast]

I think the root cause is that the google-cloud-bigquery package lives in the google.cloud namespace.

I think the solution is to create a google-namespace and a google-cloud-namespace package https://github.com/conda-forge/staged-recipes/wiki/Namespace-packages but I'm somewhat frustrated that some Conda versions seem to work fine.

[max-sixty]

I saw you did some work on airflow - do you know how they handle it?

TBH this is the most unfamiliar area for me (I don't use conda). But happy to jump in if you're taking a pause from your recent heavy contribs!

[tswast]

As I understand it, Airflow doesn't use Conda on CI. (I also doesn't test the GCP operators on CI 😭.)

[tswast]

It'll probably be next week Friday before I get a good chunk of time to do pandas-gbq stuff if you wanted to take a stab at it.

[max-sixty]

doesn't test the GCP operators on CI

😱

Looks like some people are working on it here: conda-forge/airflow-feedstock#15

[tswast]

With CircleCI and the miniconda3 container, the packages are installing okay (that was the problem on Travis). Strangely, the pandas DataFrame is getting Nones instead of float.nans for NULL floating point values.

_____ TestReadGBQIntegration.test_should_properly_handle_null_floats[env] ______

self = <tests.system.test_gbq.TestReadGBQIntegration object at 0x7f9779df0ba8>
project_id = 'pandas-gbq-tests'

    def test_should_properly_handle_null_floats(self, project_id):
        query = "SELECT FLOAT(NULL) AS null_float"
        df = gbq.read_gbq(
            query,
            project_id=project_id,
            credentials=self.credentials,
            dialect="legacy",
        )
>       tm.assert_frame_equal(df, DataFrame({"null_float": [np.nan]}))
...
/opt/conda/envs/test-environment/lib/python3.6/site-packages/pandas/util/testing.py:1010: in assert_attr_equal
    left_attr, right_attr)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

obj = 'Attributes', message = 'Attribute "dtype" are different'
left = dtype('O'), right = dtype('float64'), diff = None

    def raise_assert_detail(obj, message, left, right, diff=None):
        if isinstance(left, np.ndarray):
            left = pprint_thing(left)
        if isinstance(right, np.ndarray):
            right = pprint_thing(right)
    
        msg = """{0} are different
    
    {1}
    [left]:  {2}
    [right]: {3}""".format(obj, message, left, right)
    
        if diff is not None:
            msg = msg + "\n[diff]: {diff}".format(diff=diff)
    
>       raise AssertionError(msg)
E       AssertionError: Attributes are different
E       
E       Attribute "dtype" are different
E       [left]:  object
E       [right]: float64

/opt/conda/envs/test-environment/lib/python3.6/site-packages/pandas/util/testing.py:1092: AssertionError

See: https://circleci.com/gh/tswast/pandas-gbq/11

I wonder if that is an issue for pandas 0.23.4 in general? It would be a surprising change of behavior if so.

[tswast]

Fixed by #234