ibis/Lobby

Ivan Ogasawara

@xmnlab

Oh sorry

The metting is tomorrow

:'( I was 1 day in the future

Scott Hajek

@scottcode

Ok, Wed Oct 23 at 3pm ET. I think that time works as well for me

Ivan Ogasawara

@xmnlab

Great :) sorry for all this mess :)

Ivan Ogasawara

@xmnlab

link to the meeting https://hangouts.google.com/call/_Q9xhtir028v0bqhURjEAEEE?no_rd

Ivan Ogasawara

@xmnlab

@/all does the same time on a Wednesday works for you? or should we create something like a doodle to decide a better time?

with a quarterly cadence our next meeting would be January 22nd 2020 a Wednesday

Scott Hajek

@scottcode

@xmnlab I think so. I bet I'm not alone in saying it's hard to know specific availability a quarter out, but I'd say put it down for similar timing, and as it gets closer we could do a doodle poll to confirm the exact timing.

Ivan Ogasawara

@xmnlab

sounds good @scottcode ! I will create an issue to track that.

Ivan Ogasawara

@xmnlab

ibis-project/ibis#2008

there is already a calendar link for ibis-dev meetings inside this issue

Scott Hajek

@scottcode

Cool, nice to have a calendar. Thanks for setting it up, @xmnlab

Ivan Ogasawara

@xmnlab

it is a pleasure :)

Ivan Ogasawara

@xmnlab

@scottcode what do you think about to move your docker recipes for postgresql to ibis-project? as current we have docker repos for impala and kudu .. maybe would be good to have your recipe into ibis-project

Scott Hajek

@scottcode

@xmnlab I like that idea. The only reason I didn't do that to start with is that I didn't have access or know how to put it there. Let me know if there's anything I can do to help migrate it to something owned by ibis-project

Ivan Ogasawara

@xmnlab

@jreback @toryhaavik @cpcloud could @scottcode and I have permission to create repo? Also we want to move forward the repo for governance stuff

Jeff Reback

@jreback

the trend nowadays is to do it in the same repo ; any reason to not do that?

Ivan Ogasawara

@xmnlab

Related to docker images, currently each recipe is on its own repo

If we should decide to do it inside the main repo, we should move the other repos too

Ivan Ogasawara

@xmnlab

I will open an issue about this.

Ivan Ogasawara

@xmnlab

ibis-project/ibis#2013

Scott Hajek

@scottcode

I like the idea of having the image specifications housed in the ibis repo, at least any that deviate from standard/official ones

Ivan Ogasawara

@xmnlab

i like that too. for the governance stuff .. I think it makes more sense to have it in a separated repo.

Christopher Ostrouchov

@costrouc

Trying to disable specific operations from backends but the related tests still seem to fail. I am writing a new backend sql server and just trying to get all tests to pass so I am removing operations from the backend at the moment and adding them as UnsupportedOperationError. Is this the correct way to make the tests skip a specific operation because it seems to be ignoring this.

def raise_unsupported_op_error(translator, expr, *args):
    msg = "SQLServer backend doesn't support {} operation!"
    op = expr.op()
    raise com.UnsupportedOperationError(msg.format(type(op)))_unsupported_ops = {k: raise_unsupported_op_error for k in _unsupported_ops}
_operation_registry.update(_unsupported_ops)

With _unsupported_ops being a list of opperations that I don't have implemented

Scott Hajek

@scottcode

I believe the correct way is with purest.mark.xfail

I meant pytest for the first part

And pytest.mark.skip

Christopher Ostrouchov

@costrouc

Gotcha -- so I need to get into the tests and specifically mark each test as skipped for a specific backend?

Scott Hajek

@scottcode

They can be used as decorators on the test methods that are not yet supported

Are they tests you’ve written?

Which tests, for example

Christopher Ostrouchov

@costrouc

Ahh so for example ops.Round does not behave as expected. I have marked that operation as unsupported but the Round tests still fail.

Scott Hajek

@scottcode

Which test suite tests that?

Christopher Ostrouchov

@costrouc

So I am guessing I need to track down the round tests and mark it as xfail for the sql server backend

Okay here is a concrete example ibis/tests/all/test_string.py::test_string[MSSQL-contains] FAILED [ 54%]. ops.Contains is already marked as unsupported

Scott Hajek

@scottcode

@costrouc You can add this kind of flag to the test:
https://github.com/ibis-project/ibis/blob/3b134518550abcf9826481d09c35e75b46bcda4c/ibis/tests/all/test_join.py#L34

@pytest.mark.skip_backends([Csv])

Christopher Ostrouchov

@costrouc

Thanks will use that!

Scott Hajek

@scottcode

Let me know if that works, cuz I'm curious to know

Christopher Ostrouchov

@costrouc

Yes it worked for example in a parametrized test

        param(
            lambda t: t.string_col.contains('6'),
            lambda t: t.string_col.str.contains('6'),
            id='contains',
            marks=pytest.mark.xfail_backends((MSSQL,)),
        ),
        param(

This marked this specific test for mssql as xfail

Scott Hajek

@scottcode

Or if it's just for specific parameters of the test, looks like you can add a marks keyword to the param()

Yep, that's what I was starting to think

Cool, now I'll know how to deal with that, too

Christopher Ostrouchov

@costrouc

At the moment just trying to get the PR to pass. I was overly ambitious adding more and more operations to a new backend :smile:

Ivan Ogasawara

@xmnlab

not sure if it is just for me .. but it seems ibis-dev/lobby gitter channel is using the new pandas logo ...

Scott Hajek

@scottcode

@xmnlab Yep, looks that way to me too

Ivan Ogasawara

@xmnlab

OT: hey everyone I hope everyone here is safe! #staysafe

Where communities thrive

People

Repo info

Activity