Restrict HDBSCAN metric options to L2 #5415

[Rvch7]

This PR restricts HDBSCAN metric option to only L2. if any other metric is used it gives error message "'metric' [given metric] not supported(only 'l2' or 'euclidean' is supported)"

[rapids-bot]

Pull requests from external contributors require approval from a rapidsai organization member with write permissions or greater before CI can begin.

[csadorf]

/ok to test

[csadorf]

Thank you very much for the contribution! Can you add a trivial unit test that explicitly tests this behavior to the test_hdbscan.py module? The tests should cover the supported arguments for metric and at least one that is not supported. In this way we can ensure consistency in the future.

[Rvch7]

@csadorf is it okay to write two unit tests one with pass condition and one with fail cases or same function with xfail mark from pytest?

[csadorf]

@csadorf is it okay to write two unit tests one with pass condition and one with fail cases or same function with xfail mark from pytest?

The xfail mark is typically used to indicate that a unit test is temporarily expected to fail, not to test failure behavior. In this case I'd prefer a single parametrized unit test in combination with pytest.raises(). The parameters would be a tuple of the metric argument and a Boolean that indicates the expected pass/fail behavior. You can use the parameters to indicate the pass/fail expectation. Please let me know if you need more guidance. Thanks a lot!

[csadorf]

/ok to test

[csadorf]

@Rvch7 Do you think you will have time to address my comments as well as the linter issues? Would love to see this included in the next release.

Please see our CONTRIBUTING guide on how to use pre-commit hooks to avoid linter issues.

[Rvch7]

@csadorf I will work on it tonight but I have some thinking to do with what you said about unit test as I am new to that. would u mind giving an example(pseudo code) of

a Boolean that indicates the expected pass/fail behavior. You can use the parameters to indicate the pass/fail expectation.

if not I will figure it out eventually.

[csadorf]

@csadorf I will work on it tonight but I have some thinking to do with what you said about unit test as I am new to that. would u mind giving an example(pseudo code) of

a Boolean that indicates the expected pass/fail behavior. You can use the parameters to indicate the pass/fail expectation.

Sure:

@pytest.mark.parametrize("param,expected_to_fail", [("abc", True), ("xyz, False)])
def test(param, expected_to_fail):
    if expected_to_fail:
        with pytest.raises(Error):
            some_func(param)
    else:
        some_func(param)

Also have a look at this test that demonstrates how to use pytest.raises in this context .

[Rvch7]

Thank you for your help @csadorf, sometimes easy things look hard at the beginning. Let me know about these changes, and also please assign me any issue you may find appropriate for me.

[dantegd]

/ok to test

[csadorf]

Thank you for addressing my change requests. Just a few more minor requests and then this should be ready to merge.

[csadorf]

/ok to test

[csadorf]

LGTM!

[csadorf]

/ok to test

[csadorf]

/ok to test

[csadorf]

/merge

[bdice]

Rerunning CI now that #5536 is merged.

[bdice]

/ok to test